استخدم منهجية التطوير القائم على الاختبارات ومجموعة الاختبارات المعطاة لحل التمارين
التطوير الموجَّه بالاختبارات (ويُسمى أحيانًا التطوير الذي يبدأ بالاختبار أو التصميم الموجَّه بالاختبارات) هو ممارسة كتابة اختبارات الوحدة أولًا، قبل أن تكتب سطرًا واحدًا من كود التنفيذ.
كل التمارين التدريبية التي تعمل عليها (تلك التي لا تعلّمك مفهومًا جديدًا) تتضمن تعليمات تصف بشكل عام ما عليك فعله. وهذه التعليمات مصممة عمدًا كي لا تراعي تفاصيل التنفيذ الخاصة بلغة برمجة بعينها، لأنها مشتركة بين أكثر من 70 مسارًا لغويًا في Exercism. وبعض المسارات اللغوية تضيف لك تفاصيل أكثر تحديدًا، لكن ليس كلها يفعل ذلك.
عندما تبدأ العمل على تمرين تدريبي، اقرأ التعليمات بتمعّن. ستمنحك نظرة عامة واسعة عن كيفية تنفيذ الحل. لكن سيتعين عليك قراءة الاختبارات لفهم المتطلبات الكاملة والدقيقة:
تكون قد حللت التمرين عندما تعمل جميع الاختبارات المرفقة وتنجح. بعبارة أخرى، حلّك ليس مجرد تفسير للتعليمات "يبدو صحيحًا"، بل هو برنامج يستوفي الاختبارات المعطاة. تمثل الاختبارات المتطلبات الكاملة للتمرين.
لقد قمنا عنك بكتابة مجموعة اختبارات الوحدة. وهدفك أن تكتب حلًا يحتوي على القدر الكافي فقط من الكود لاجتياز كل اختبارات الوحدة تلك.
ضع هذا في اعتبارك: نهج TDD سيساعدك على الوصول إلى الحل، لكنك لست مضطرًا للتوقف عند هذا الحد. إذا أردت توسيع حلّك بما يتجاوز المتطلبات، فلك ذلك. وإذا اخترت العمل مع مُرشد (ونشجعك على ذلك بمجرد أن تنجح الاختبارات)، فيمكنه مساعدتك على إعادة هيكلة تنفيذك الأولي وصقله، أو حتى اقتراح اختبارات وحدة جديدة.
عندما تعمل في محرر الكود على موقع Exercism، يمكنك قراءة الاختبارات لكن لا يمكنك تعديلها. ستُنفَّذ جميع الاختبارات في كل مرة تشغّلها، بصرف النظر عن أي آليات "تخطي" مذكورة في ملف الاختبار.
وعندما تفشل عدة اختبارات، لا يعرض الموقع في البداية سوى نتائج أول فشل. ويمكنك النقر على حالات الفشل الأخرى لتوسيعها أيضًا! أحيانًا قد لا تكون النتيجة الأولى هي الأكثر إفادة.
لا تيأس من كثرة الاختبارات الفاشلة. ركّز على اجتيازها واحدًا تلو الآخر.
تستخدم مسارات كثيرة اختبارات "متخطّاة" في ملفات اختباراتها. في البداية يكون الاختبار الأول وحده "نشطًا" وتكون البقية غير نشطة (وتختلف طريقة حدوث ذلك من مسار إلى آخر). وعندما تشغّل مجموعة الاختبارات في بيئتك، لن يعمل سوى الاختبار الأول. ونحن نفعل ذلك لنشجعك على اتباع سير العمل هذا:
كرّر هذه الخطوات حتى تلغي تخطي جميع الاختبارات. وبمجرد أن تنجح جميع الاختبارات، تهانينا، لقد حللت التمرين!
تعتمد الطريقة الدقيقة لإلغاء تخطي الاختبارات (أو تنشيطها) على المسار.
في بعض المسارات قد يكون الأمر تعليق سطر توضيحي أو إزالته.
وفي بعضها الآخر قد يكون تغيير سمة من true إلى false.
خذ وقتك في قراءة وثائق مسارك؛ فهي تشرح هذه التفاصيل.
أما المسارات التي لا تتخطى الاختبارات، فقد يكون تطبيق سير العمل هذا بسيطًا كتعليق الاختبارات ثم إلغاء التعليق عنها واحدًا تلو الآخر.
قد يبدو هذا كأنه "وضع العربة أمام الحصان"، لكن هناك عدة أسباب وجيهة قد تدفعك إلى كتابة اختبارات الوحدة قبل كتابة كود التنفيذ.
التصميم. فهو يدفعك إلى التفكير أولًا في واجهة برنامجك (كيف يعرض وظائفه للعالم)، بدلًا من القفز مباشرة إلى كيفية تنفيذ الكود. وغالبًا ما تكون الواجهة المصممة جيدًا (والقابلة للاختبار!) أهم من التنفيذ الفعّال.
الانضباط. كثيرًا ما يُنظر إلى كتابة الاختبارات كعبء أو فكرة لاحقة؛ لكن كتابة الاختبارات أولًا تضمن لك أن تكون قد كتبت في نهاية المطاف ما يكفي من اختبارات الوحدة لتغطية معظم وظائف كودك أو كلها (بدلًا من ألا تجد الوقت لذلك أبدًا).
جهد أقل. إذا التزمت بدورة محكمة: اكتب اختبارًا واحدًا، ثم اكتب الكود الذي ينفّذه، ثم اكتب الاختبار التالي، فسينمو كودك بشكل عضوي. وهذا غالبًا (وليس دائمًا) يؤدي إلى جهد مهدر أقل؛ إذ تكتب كل الكود الذي تحتاجه، ولا تكتب أي كود لا تحتاجه.