ما الذي حلّه الاختبار بدون كود فعلاً

  • إتاحة التأليف. من يعرف المنتج ولا يعرف إطار عمل يستطيع بناء اختبار. هذا حقيقي، وله أهميته.

  • قابلية القراءة لغير المهندسين. التدفّق المرئي مفهوم لمدير المنتج على نحو لا يكون فيه ملف الكود كذلك.

  • اختبارات أولى أسرع. انخفض الزمن اللازم للوصول إلى أول فحص عامل انخفاضًا كبيرًا.

ما الذي نقله بدل أن يزيله

الصيانة

  • إعادة التصميم تكسر الخطوات المسجّلة تمامًا كما تكسر المحدِّدات.

  • صار الإصلاح بالنقر لا بالكتابة.

المراجعة

  • التدفّق المرئي لا يقبل المقارنة بين النسخ. ومراجعة أي تغيير تعني فتح المحرّر.

التحكم في الإصدارات

  • تعيش التدفّقات داخل منصّة بدل أن تكون بجوار الكود الذي تختبره.

لا شيء من هذا قاتل. لكنها الأسباب التي جعلت الوعد يبدو ناقصًا، وهي تفسّر لماذا تتعثّر كثير من مجموعات الاختبار بدون كود بعد الربع الأول.

الافتراض الكامن خلفها

تفترض منصّات الاختبار بدون كود وجود شخص مهمته بناء تدفّقات الاختبار. فحين يوجد هذا الدور تعمل المنصّات جيدًا، وحين لا يوجد تبقى المنصّة بلا استخدام، لأن المطوّرين عادةً لا يستخدمون محرّرًا مرئيًا، ولا أحد غيرهم يفعل.

سقوط هذا الافتراض هو السبب الأشيع لتوقف مجموعة اختبارات بدون كود عن النمو، وهو سبب تنظيمي لا تقني.

مشكلة التسليم

ثمة خلل خاص بهذه الفئة يستحق التخطيط لتفاديه، لأنه يقع فجأة لا تدريجيًا.

يبني التدفّقات المرئية شخص واحد، وهي مقروءة لأي شخص، وهو ما يبدو نقيض مشكلة «عامل الحافلة». غير أن المقروء ليس هو نفسه القابل للصيانة. فتدفّق من ثلاثين خطوة وفروع شرطية ومتغيّرات مشتركة لا يقل تعقيدًا عن الكود، ومن بناه يحمل في ذهنه تصوّرًا لسبب وجود كل خطوة لا يُظهره المحرّر.

وعند رحيل من بناها، تظل التدفّقات تعمل إلى أن يتغيّر شيء ما، فلا يعرف أحد عندئذ أي الخطوات كانت حاملةً أساسية. أما الكود فيحمل على الأقل تعليقات وسجل تعديلات. والعلاج هو اشتراط وصف مكتوب موجز على كل تدفّق يشرح ما الذي يحميه، وهو ما يبدو زائدًا عن الحاجة ما دام صاحبه موجودًا، وهو الشيء الوحيد الذي يبقى بعد الرحيل.

ما الذي يغيّره الجيل الأحدث

وصف الفحص بلغة عادية وترك بنائه وصيانته لوكيل ذكي يحافظ على سهولة الوصول ويُلغي خطوة التأليف تمامًا. كما أن الخطوات المعبَّر عنها كنوايا تصمد أمام عمليات إعادة التصميم التي تكسر التدفّقات المسجّلة، وهناك كان يذهب معظم جهد الصيانة.

والمقايضة هي أنك تراجع تغطيةً لم تبنِها بنفسك، وهذه مهارة مختلفة عن بنائها.

لا شيء من هذا يحتاج إلى طرفية. أنشئ مشروعًا في لوحة تحكم TestSprite، وصِف الفحص بلغة عادية، ووجّهه إلى تطبيقك. ويستطيع المطوّرون في فريقك تشغيل الشيء نفسه من سطر الأوامر إن فضّلوا ذلك، وهو متاح في مستودع CLI.

اربط المستودع من لوحة التحكم لتنطلق عمليات التشغيل من النشر الذي تنتجه أصلًا، أو أضِف خطوة إلى سير عملك الخاص بدلًا من ذلك.

ما الذي يغيّره وصف الفحص

خطوة التأليف تختفي بدل أن تتحوّل إلى صيغة مرئية. تقول بلغة عادية ما الذي ينبغي أن يكون صحيحًا، ويتولّى TestSprite استنتاج كيفية فحصه، فلا تعود التغطية معتمدة على شخص يجلس أمام محرّر يبني التدفّقات.

كما تنخفض الصيانة التي نقلها الاختبار بدون كود بدل أن يزيلها، لأن الخطوات تُخزَّن كنوايا لا كمسارات مسجّلة. فإعادة تصميم تنقل زرًّا من مكانه لا تكسر الفحص، وقد كان ذلك أكبر تكلفة متكررة في الجيل السابق.

وما يطلبه منك في المقابل هو مراجعة تغطية لم تبنِها بنفسك. وهذه مهارة مختلفة عن بنائها، والتزام زمني أصغر كثيرًا، وهي المقايضة التي تستحق الفهم قبل تبنّي أي من النهجين.

هل يستحق الاختبار بدون كود العناء؟

إن كان لديك شخص مهمته بناء تدفّقات الاختبار، فنعم. وإن لم يكن، فستبقى المنصّة بلا استخدام مهما بلغت جودتها.

هل يمكن للمطوّرين وغير المطوّرين أن يتشاركوا مجموعة اختبارات واحدة؟

نظريًا نعم. أما عمليًا فالمطوّرون يتجنّبون المحرّرات المرئية، ولذلك تعني الملكية المشتركة عادةً أن مجموعة واحدة هي التي تتولى الصيانة.

وماذا عن التحكم في الإصدارات؟

هذه هي نقطة الضعف. اسأل كيف تُراجَع التغييرات وكيف يمكنك التراجع عن أحدها، قبل أن تلتزم.

هل يحل وصف الفحوص بلغة عادية محل الاختبار بدون كود؟

إنه يُلغي خطوة التأليف مع الحفاظ على سهولة الوصول، ويطلب منك أن تراجع بدل أن تبني.

كيف ننقل مجموعة اختبارات قائمة بدون كود؟

تعامل مع التدفّقات بوصفها مواصفةً لما هو مهم. تلك القائمة هي الجزء القيّم؛ أما التسجيلات فنادرًا ما تنتقل.

الخلاصة

لقد نقل الصيانة، ولم يُزلها.

حلّ الاختبار بدون كود مسألة إتاحة التأليف، ونقل الصيانة والمراجعة والتحكم في الإصدارات إلى مكان آخر. وهو يفترض وجود شخص مهمته بناء التدفّقات، وحيث لا يوجد هذا الشخص تتعثّر مجموعة الاختبارات.