تجاوز إلى المحتوى
تعلّم لعملك المرجع مقالات المحفوظات
العربية

playbook

اكتب الـ tests التي لم تكتبها قط

خذ module بلا tests، واجعل Claude يُعدّد السلوكيات الجديرة بالتثبيت — بما فيها الـ edge cases الخبيثة — ويكتب suite يغطّيها، مع التنبيه على أي bugs كامنة يجدها في الطريق.

متوسّط ~30 دقيقة

متى تلجأ إلى هذا

ثمّة module يخشى الجميع مسّه لأنه بلا tests. تريد تغييره، لكن دون شبكة أمان يصبح كل تعديل مقامرة. هذا النظام يحوّل «غير مُختبَر ومخيف» إلى «مُغطّى وآمن للـ refactor» — وكتابة الـ tests نفسها تُخرِج عادةً bug أو اثنين كانا مختبئين طوال الوقت.

جهّز هذا أولًا

  • الملف أو الـ module الذي تريد تغطيته، مفتوحًا في الـ repo حتى يقرأ Claude التنفيذ الفعلي.
  • كيف تشغّل الـ tests في هذا المشروع — الـ command والـ framework (vitest، pytest، go test)، حتى تناسب الـ suite إعدادك.
  • أي سلوكيات تعرف مسبقًا أنها مهمّة — الـ edge cases التي أحرقتك من قبل.

الـ workflow

  1. عدّد السلوكيات قبل كتابة أي test

    لا تطلب tests بعد. اطلب جردًا لما يُفترض أن يفعله هذا الكود — الـ happy path و، الأهمّ، الحواف. ستلتقط حالة مفقودة هنا.

    أنت تطلب 
    اقرأ هذا الـ module. قبل كتابة أي tests، عدّد كل سلوك جدير بالتثبيت — المسارات العادية والـ edge cases الخبيثة (input فارغ، قيم null، الحدود، استدعاءات متزامنة، مسارات الخطأ). نبّه على أي شيء يبدو أصلًا كأنه bug كامن.

    ما تحصل عليه checklist بالسلوكيات مجمّعة في happy-path وedge-case، إضافة إلى قائمة قصيرة بـ «هذا يبدو مريبًا» — الـ spec الذي لم يُكتب لهذا الكود قط.

    قائمة الـ edge cases هي الجزء القيّم. الـ happy path كنت ستختبره على أي حال؛ الحدود هي حيث تعيش الـ bugs.

  2. اكتب الـ suite مقابل تلك القائمة

    حوّل الجرد الآن إلى tests حقيقية في الـ framework لديك، مسمّاةً بحيث يعرف قارئٌ مستقبلي ما الذي انكسر حين يصير أحدها أحمر.

    أنت تطلب 
    اكتب test suite يغطّي تلك القائمة باستخدام إعداد الـ tests لدينا. سمِّ كل test باسم السلوك الذي يثبّته، غطِّ الـ edge cases صراحةً، وأبقِ كل test مركّزًا على شيء واحد. لا تُغيّر الـ module بعد.

    ما تحصل عليه suite سهل القراءة، كل test فيه يقابل سلوكًا من الخطوة 1 — الـ edge cases كـ cases مسمّاة بذاتها، لا مدفونة في test واحد عملاق.

  3. شغّله وواجِه الإخفاقات

    بعض الـ tests الجديدة قد يفشل مقابل الكود الحالي. هذا ليس bug في الـ tests — هذا الـ suite يثبت جدارته.

    أنت تطلب 
    شغّل الـ suite. لأي شيء يفشل، أخبرني هل الـ test خاطئ أم الكود — لا «تُصلح» الـ test ببساطة لتجعله ينجح. إن كان bug حقيقيًا، أرِني أصغر إصلاح.

    ما تحصل عليه إمّا أخضر، وإمّا فصلٌ صادق: «هذان الإخفاقان bugs حقيقية في الـ module، وهذه أخطاء في tests كتبتها» — مع إصلاح مقترح للحقيقية، منفصلًا عن الـ tests.

    احذر النمط المُغري المضادّ: جعل test فاشل ينجح بإضعاف الـ assertion. test لا يستطيع أن يفشل لا يحمي شيئًا.

اجعله ملكك

  • **Characterization أولًا:** للكود الذي لا تفهمه فهمًا كاملًا، اطلب *characterization tests* تثبّت السلوك الحالي تمامًا كما هو — حتى نزواته — كي تستطيع الـ refactor بأمان قبل أن تقرّر ما هو الـ bug.
  • **فجوة في الـ coverage:** وجّهه إلى coverage report — «ها هي الأسطر غير المُغطّاة، اكتب tests تُمرّنها» — لإغلاق ثغرات محدّدة بدل إعادة اختبار ما هو أخضر أصلًا.

انتبه إلى

  • لا تدعه يجعل test فاشلًا ينجح بتليين الـ assertion. اسأل صراحةً: هل الـ test خاطئ أم الكود؟ suite أخضر لا يؤكّد شيئًا أسوأ من لا suite إطلاقًا.
  • الـ tests التي تعكس التنفيذ سطرًا بسطر تنكسر مع كل refactor ولا تلتقط شيئًا. اختبر *السلوك والعقود*، لا الأمور الداخلية.
  • اقرأ الـ tests المُولَّدة — test خاطئ ينجح يُرسّخ اعتقادًا خاطئًا عن كودك وسيُضلّل الشخص التالي.

ستحصل في النهاية على module مخيف وغير مُختبَر يصير module مُغطّى تستطيع تغييره بثقة — وكتابة الـ suite نفسها تُخرِج الـ bug أو الاثنين الحقيقيين اللذين كانا مختبئين في الـ edge cases.