الاختبارات هي حيث يستحقّ Claude Code أجره. التصحيح هو حيث يصير مذهلًا بشكل غريب.

لكنّه أيضًا حيث ينحرف workflow مهلهل بسرعة. اترك وكيلًا "يصلح" اختبارًا بطريقة خاطئة، فتشحن CI خضراء بميزة مكسورة. اتركه "يُصحّح" اختبارًا متذبذبًا، فربّما يحذف الاختبار.

إليك الأنماط الناجحة — والقاعدة التي تُبقيها أمينة.

القاعدة الواحدة

شغّلها بـ sub-agentَين لا يمكن أن يكونا نفس الوكيل:

• test-writer — يضيف أو يعدّل الاختبارات فقط.
• test-fixer — يعدّل كود الإنتاج فقط ليجعل الاختبارات تنجح.

إن أراد test-fixer يومًا لمس اختبار، فعليه التصعيد لإنسان. هذا العقد.

النمط 1 — تفويض test-first

للميزات الجديدة، هذا أنظف workflow:

> /agents test-writer
> الهدف: اكتب حالات vitest لـ lib/cache.ts تغطّي:
>   - إخلاء LRU عند maxSize=3
>   - انتهاء TTL تحت fake timers
>   - get(missing) يرجع undefined
> القيود: vitest، fake timers عبر vi.useFakeTimers().
> DoD: الاختبارات مكتوبة، كلّها حاليًا حمراء.

المخرَج اختبارات فاشلة. هذا صحيح.

> /agents test-fixer
> اجعل الاختبارات الجديدة تنجح دون تعديل tests/cache.test.ts.

ينفّذ test-fixer LRU + TTL في lib/cache.ts. تخضرّ الاختبارات. الـ diff صغير، مركّز، قابل للمراجعة.

هذا أنظف بكثير من "اكتب الكاش والاختبارات دفعة واحدة" لأنّ كاتب الاختبارات أعمى تجاه التنفيذ. يُمسك أخطاء الـ API مبكّرًا.

النمط 2 — هامس stack-trace

عندما ينفجر شيء في logs الإنتاج، الصق stack trace. Claude Code جيّد بشكل غير معقول هنا.

> اقرأ stack trace هذه وأخبرني أيّ من الأسباب الثلاثة الأكثر احتمالًا صحيح،
  مع أدلّة ملف:سطر:

[الصق الـ stack]

ثمّ اقترح إصلاحًا من 5 أسطر يعالج هذا السبب فقط.

ملاحظتان:

• "ثلاثة أسباب الأكثر احتمالًا" يجبره على التعداد، لا على الإفراط في الالتزام.
• "إصلاح من 5 أسطر" يحدّ من نطاق الضرر.

أجد أنّ ~70% من جلسات تصحيح "ماذا يحدث هنا؟" تنتهي بعد هذه الجولة الواحدة.

النمط 3 — فرز اختبارات flaky

اختبارات flaky هي بلاء CI. الوكيل ممتاز في تصنيفها:

> شغّل مجموعة الاختبارات 10 مرّات. اذكر أيّ اختبار:
>   - فشل مرّة على الأقل ونجح مرّة على الأقل.
>   - أخرج الخطأ الدقيق من التشغيل الفاشل.
> لا تُعدّل أيّ كود.

تستعيد جدول فرز. ثمّ تسأل:

> للاختبار X (flaky)، صنّف السبب المرجّح:
>   - race condition
>   - يعتمد على الوقت (ساعة حقيقيّة مقابل fake)
>   - شبكة / اعتماديّة خارجيّة
>   - تسرّب موارد من اختبار سابق
> اذكر أدلّة ملف:سطر.

تصنيف الوكيل نادرًا ما يكون 100% صحيحًا لكنّه دائمًا تقريبًا "في الحيّ الصحيح". وهذا يكفي لتوجيه تحقيقك في الاتّجاه الصحيح.

النمط 4 — bisect لـ regression

عندك git bisect وعند الوكيل git log. اجمعهما:

> رجعت /api/x بـ 200 الأسبوع الماضي وترجع الآن 500.
> اعثر على الـ commit المُسبّب عبر:
>   1. git log --oneline منذ آخر نشر جيّد.
>   2. لكلّ commit يلمس /api/x أو استيراداتها، لخّص التغيير في سطر واحد.
>   3. حدّد المشتبه الأرجح واشرح لماذا.
>   4. لا تُشغّل أيّ كود.

هذا أسرع من git bisect ثنائيّ لأنّ الوكيل يقرأ الـ diffs أثناء العمل. الأنسب لقواعد كود صغيرة بحيث تكون مجموعة المرشّحين < 50 commit.

النمط 5 — التغطية كحلقة تدريب

هذا غير مقدّر بما يكفي:

> شغّل pnpm test --coverage على lib/auth/.
> أبلِغ بالأسطر غير المغطّاة.
> لكلّ فرع غير مغطّى، اقترح وصفًا في سطر واحد لاختبار يغطّيه.
> لا تكتب الاختبارات.

تستعيد punch list. ثمّ يقضي عليها test-writer واحدة تلو الأخرى.

سبب أفضليّة ذلك على "حقّق 90% تغطية تلقائيًا": أنت ترى punch list ويمكنك خفض أولوية الفروع التافهة (مسارات أخطاء يستحيل ضربها، defaults exhaustive-switch).

أمور لا يجب تفويضها في الاختبارات

• اختيار ما يُختبر. هذه معرفة منتج.
• تحديد متى يكون "جيّدًا بما يكفي" جيّدًا بما يكفي. عتبات التغطية قرار قيم.
• وضع علامة "skip" أو "todo" على اختبار. دائمًا بشريّ. دائمًا.

يقترح الوكيل؛ ويقرّر الإنسان ما يُعدّ جاهزًا.

أنماط مضادّة في التصحيح أراها أسبوعيًا

• "اجعل الاختبار ينجح وحسب." كارثيّ. دائمًا. سيُمسكها الـ reviewer؛ لا ينبغي أن يُطلب ذلك من الوكيل.
• "أضف // @ts-ignore لإسكات الـ build." ينبغي للـ sub-agent أن يرفض. اضبطه هكذا في .claude/agents/test-fixer.md:

# قواعد
- لا تُضف أبدًا @ts-ignore أو @ts-expect-error أو eslint-disable.
- إن لم تستطع إصلاح خطأ نوع، فقم بالتصعيد.

• "حدّث الـ snapshot." أحيانًا مشروع، لكن ينبغي للوكيل أن يُظهر دائمًا الـ diff ويشرح لماذا تغيّر الـ snapshot قبل تحديثه.

النتيجة بعد ربع سنة

على قاعدة الكود التي أشغّل عليها هذا منذ ~3 أشهر:

• متوسّط زمن فرز CI flaky: ~12 دقيقة → ~3 دقائق.
• متوسّط زمن تصحيح stack trace من الإنتاج: ~20 دقيقة → ~5 دقائق.
• دلتا تغطية الاختبارات على الميزات الجديدة: متذبذبة، لكنّها بمتوسّط +8 نقاط مئويّة.

لا شيء من هذه الأرقام بسحر الوكيل. كلّها نتيجة توحيد workflow الاختبارات بقيود لا يمكن توحيدها بسهولة حول البشر.

---

المقال التالي: سير العمل داخل الفرق — كيف تدمج فرق الهندسة Claude Code اليوم، من النمط المضادّ "ترخيص واحد" إلى النمط المشترك .claude/ في git الذي يتوسّع.