ما الذي أحتاج تجهيزه قبل البدء؟

الملف أو الـ module الذي تريد تغطيته (افتح مجلد المشروع في Claude Desktop كي يقرأ Claude التنفيذ الفعلي — لا حاجة لـ Terminal لقراءة الـ tests أو كتابتها)، والـ command والـ framework الذي تستخدمه لتشغيل الـ tests (مثل vitest، أو pytest، أو go test)، وأي edge cases تعرف مسبقًا أنها تسبّبت في مشاكل. Claude يستطيع استنتاج الكثير، لكن معرفة الـ test runner مسبقًا تعني أن الـ suite الذي يكتبه سيلائم مشروعك فعلًا.

ماذا لو فشل بعض الـ tests الجديدة مقابل الكود الموجود — هل هذه مشكلة؟

لا — test فاشل مقابل الكود الموجود هو الـ suite يُثبت جدارته، لا خطأ. تشغيل الـ suite هو الخطوة الوحيدة في مسار Power Track التي تحتاج جلسة مفعّلة للـ Terminal؛ إن لم تكن لديك واحدة، شغّله بنفسك والصق الإخفاقات في المحادثة. في الحالتين، السؤال المحوري الذي يجب طرحه على Claude هو: هل كل إخفاق يعني أن الـ test خاطئ أم الكود خاطئ؟ لا تسمح له أبدًا بإضعاف assertion لمجرد تحويل test إلى أخضر؛ هذا ينتج suite لا يستطيع حمايتك.

كيف أتجنّب tests تعكس التنفيذ سطرًا بسطر وتنكسر مع كل refactor؟

اطلب من Claude إدراج السلوكيات والعقود أولًا (الخطوة 1)، ثم كتابة tests مقابل تلك القائمة — لا مقابل أسطر التنفيذ. الـ tests المسمّاة بأسماء السلوكيات (مثل «تُعيد null حين يكون الـ input فارغًا») تصمد أمام الـ refactor؛ أما الـ tests التي تستدعي private methods سطرًا بسطر فلا.

هل يمكنني استخدام هذا لإغلاق ثغرات محدّدة في coverage report بدل تغطية module كامل؟

نعم — وجّه Claude إلى الـ coverage report وقل «ها هي الأسطر غير المُغطّاة، اكتب tests تُمرّنها». هذا أسرع من إعادة اختبار ما هو أخضر أصلًا، ويعمل بشكل ممتاز حين تملك تغطية جزئية وتريد فقط سدّ الفجوات.

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

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

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

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

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

الـ workflow

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

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

أنت تطلب

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

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

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

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

أنت تطلب

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

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

بعض الـ tests الجديدة قد يفشل مقابل الكود الحالي. هذا ليس bug في الـ tests — هذا الـ suite يثبت جدارته. تشغيل الـ test command الخاص بمشروعك خطوة في مسار Power Track (جلسة مفعّلة للـ Terminal)؛ إن لم تكن لديك واحدة، شغّل الـ suite بنفسك والصق الإخفاقات في محادثة Claude Desktop — المواجهة هي نفسها في الحالتين.

أنت تطلب

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

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

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

اجعله ملكك

Characterization أولًا: للكود الذي لا تفهمه فهمًا كاملًا، اطلب characterization tests تثبّت السلوك الحالي تمامًا كما هو — حتى نزواته — كي تستطيع الـ refactor بأمان قبل أن تقرّر ما هو الـ bug.
فجوة في الـ coverage: وجّهه إلى coverage report — «ها هي الأسطر غير المُغطّاة، اكتب tests تُمرّنها» — لإغلاق ثغرات محدّدة بدل إعادة اختبار ما هو أخضر أصلًا.
هذا الـ suite الأخضر حزام أمان — اربطه قبل خطوتك التالية. الغاية كلها من تغطية الـ module المخيف هي ما تفعله بعده: سلّم الـ suite الأخضر الآن مباشرةً إلى playbook الـ safe-refactor، الذي يشغّله قبل كل تغيير وبعده كي يكون السلوك ثابتًا بدليل. وأي bug كامن أظهره هذا لا «يُصلَح» في مكانه — وجّهه إلى playbook الـ debug-from-trace، حيث ينال test خاصًّا به ينتقل من فاشل إلى ناجح بدل أن يُمتَصّ بصمت.

انتبه إلى

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

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

أسئلة يطرحها الناس

ما الذي أحتاج تجهيزه قبل البدء؟: الملف أو الـ module الذي تريد تغطيته (افتح مجلد المشروع في Claude Desktop كي يقرأ Claude التنفيذ الفعلي — لا حاجة لـ Terminal لقراءة الـ tests أو كتابتها)، والـ command والـ framework الذي تستخدمه لتشغيل الـ tests (مثل `vitest`، أو `pytest`، أو `go test`)، وأي edge cases تعرف مسبقًا أنها تسبّبت في مشاكل. Claude يستطيع استنتاج الكثير، لكن معرفة الـ test runner مسبقًا تعني أن الـ suite الذي يكتبه سيلائم مشروعك فعلًا.
ماذا لو فشل بعض الـ tests الجديدة مقابل الكود الموجود — هل هذه مشكلة؟: لا — test فاشل مقابل الكود الموجود هو الـ suite يُثبت جدارته، لا خطأ. تشغيل الـ suite هو الخطوة الوحيدة في مسار `Power Track` التي تحتاج جلسة مفعّلة للـ Terminal؛ إن لم تكن لديك واحدة، شغّله بنفسك والصق الإخفاقات في المحادثة. في الحالتين، السؤال المحوري الذي يجب طرحه على Claude هو: هل كل إخفاق يعني أن الـ test خاطئ أم الكود خاطئ؟ لا تسمح له أبدًا بإضعاف assertion لمجرد تحويل test إلى أخضر؛ هذا ينتج suite لا يستطيع حمايتك.
كيف أتجنّب tests تعكس التنفيذ سطرًا بسطر وتنكسر مع كل refactor؟: اطلب من Claude إدراج السلوكيات والعقود أولًا (الخطوة 1)، ثم كتابة tests مقابل تلك القائمة — لا مقابل أسطر التنفيذ. الـ tests المسمّاة بأسماء السلوكيات (مثل «تُعيد null حين يكون الـ input فارغًا») تصمد أمام الـ refactor؛ أما الـ tests التي تستدعي private methods سطرًا بسطر فلا.
هل يمكنني استخدام هذا لإغلاق ثغرات محدّدة في coverage report بدل تغطية module كامل؟: نعم — وجّه Claude إلى الـ coverage report وقل «ها هي الأسطر غير المُغطّاة، اكتب tests تُمرّنها». هذا أسرع من إعادة اختبار ما هو أخضر أصلًا، ويعمل بشكل ممتاز حين تملك تغطية جزئية وتريد فقط سدّ الفجوات.