أماكن إجراء الاختبارات

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

النص البرمجي للمتطلبات الأساسية

عادةً ما تحتوي مشاريع الويب على ملف إعداد، وهو ملف package.json الخاص بها، يتم إعداده من خلال npm أو pnpm أو Bun أو ما شابه. يحتوي ملف التكوين هذا على تبعيات مشروعك ومعلومات أخرى، بالإضافة إلى النصوص البرمجية المساعدة. قد تتضمن هذه البرامج النصية المساعدة كيفية إنشاء مشروعك أو تشغيله أو اختباره.

في package.json، عليك إضافة نص برمجي باسم test يصف كيفية إجراء الاختبارات. وهذا مهم لأنه عند استخدام npm أو أداة مشابهة، يكون النص البرمجي"test" له معنى خاص. يمكن أن يشير هذا النص البرمجي إلى ملف واحد يعرض استثناءً، مثل node tests.js، ولكننا ننصح باستخدامه للإشارة إلى برنامج تشغيل تجريبي محدد.

إذا كنت تستخدم Vitest كمشغّل الاختبار، سيظهر ملف package.json على النحو التالي:

{
  "name": "example-project",
  "scripts": {
    "start": "node server.js",
    "test": "vitest --run"
  }
}

يؤدي تشغيل npm test مع هذا الملف إلى تشغيل مجموعة الاختبارات التلقائية في Vitest مرة واحدة. في Vitest، يكون الإعداد الافتراضي هو البحث عن جميع الملفات التي تنتهي بـ ".test.js" أو مشابهة وتشغيلها. اعتمادًا على مُجري الاختبار الذي اخترتَه، قد يكون الأمر مختلفًا قليلاً.

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

استدعاء الاختبار اليدوي

قد يكون إجراء الاختبارات الآلية يدويًا (مثل استخدام npm test في المثال السابق) عمليًا أثناء العمل بنشاط على قاعدة رموز برمجية. يمكن أن تساعدك كتابة اختبارات إحدى الميزات أثناء تطويرها في الحصول على فكرة عن الطريقة التي يجب أن تعمل بها الميزة، وهذا يتمحور حول مفهوم التطوير المستند إلى الاختبار (TDD).

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

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

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

إجراء الاختبارات كجزء من عملية الإرسال المُسبَق أو المراجعة

تختار العديد من المشاريع التأكّد من أنّ قاعدة الرموز تعمل بشكل صحيح عند إعادة دمج الرمز في فرع main الخاص بها. إذا كنت جديدًا في الاختبار، ولكنك ساهمت في مشروعات مفتوحة المصدر في الماضي، فربما لاحظت أن جزءًا من عملية طلب السحب (PR) يؤكد أن جميع اختبارات المشروع تجتاز، مما يعني أن مساهمتك الجديدة والمثيرة لم تؤثر سلبًا على المشروع الحالي.

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

على سبيل المثال، يشير GitHub إلى هذه الإجراءات باسم "عمليات التحقّق من الحالة" التي يمكنك إضافتها من خلال إجراءات GitHub. تُعدّ إجراءات GitHub نوعًا من الاختبارات في الأساس، إذ يجب أن تنجح كل خطوة (لا تفشل، أو ترمي Error) لاجتياز الإجراء. يمكنك تطبيق "المهام" على جميع "المسؤولين التنفيذيين" لمشروع ما، ويمكن أن يتطلب المشروع أن تجتاز الإجراءات قبل المساهمة بالرمز. يشغِّل إجراء Node.js التلقائي في GitHub npm test كإحدى خطواته.

ويحاول هذا النهج المتّبع في الاختبار التأكّد من أنّ قاعدة الرموز لديك دائمًا "خضراء" من خلال عدم قبول الكود الذي لا يجتاز اختباراته بنجاح.

إجراء الاختبارات كجزء من "الدمج المستمر"

بعد قبول العلاقات العامة الخضراء، تُجري معظم قواعد الترميز اختبارات مرة أخرى استنادًا إلى فرع main الخاص بالمشروع، بدلاً من الإصدار السابق. قد يحدث هذا فورًا أو بشكل منتظم (على سبيل المثال، كل ساعة أو كل ليلة). غالبًا ما تظهر هذه النتائج كجزء من لوحة معلومات التكامل المستمر (CI) التي تُظهر الحالة العامة للمشروع.

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

• تم قبول العديد من التغييرات "دفعة واحدة"، والتي تُعرف أحيانًا باسم حالة العِرق، وتؤثر في بعضها البعض بطرق خفية وغير اختبارية.
• اختباراتك لا يمكن تكرارها، أو أنها تختبر رمزًا "غير مستقر"؛ يمكن أن تجتاز اختباراتك وتفشل بدون إجراء تغييرات على التعليمات البرمجية.
  • قد يحدث هذا إذا كنت تعتمد على أنظمة خارجية عن قاعدة الرموز الخاصة بك. بالنسبة إلى الخادم الوكيل، تخيَّل إجراء الاختبار إذا كان Math.random() > 0.05، سيؤدي إلى تعذُّر ذلك عشوائيًا بنسبة 5% من الوقت.
• بعض الاختبارات مكلفة جدًا أو مكلفة للغاية ليتم إجراؤها في كل العلاقات العامة، مثل الاختبارات الشاملة (مزيد من المعلومات حول هذا الأمر في أنواع الاختبارات الآلية)، ويمكن أن تتعطّل بمرور الوقت بدون تنبيه دائمًا.

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

استراحة حول العودة

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

بالنسبة للمشروعات الصغيرة، قد يكون حدسك هو التعامل معها باعتبارها أزمة! أوقف كل شيء وارجع التغيير المسيء أو رجعه إلى الحالة الجيدة المعروفة. يمكن أن يكون هذا منهجًا صالحًا، ولكن من المهم تذكُّر أنّ الاختبار (والبرامج بشكل عام) هو هدف لتحقيق غاية، وليس هدفًا في حد ذاته. ربما يكون هدفك هو كتابة برامج، وليس اجتياز جميع الاختبارات. بدلاً من ذلك، يمكنك إعادة توجيه التغيير من خلال إجراء تغيير آخر لإصلاح الاختبارات التي تعذّر إجراؤها.

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

لا يتوفر حل سريع لهذه المشكلة، ولكن يمكن أن يساعد ذلك في أن تصبح أكثر ثقة في كتابة الاختبارات (تحسين المهارات)، وتقليل نطاق الاختبارات (التبسيط) بحيث يمكن تحديد حالات الإخفاق بسهولة أكبر. إنّ العدد المتزايد من اختبارات المكوّنات أو اختبارات الدمج (المزيد حول الأنواع في أنواع الاختبار التلقائي) يمكن أن يوفر ثقة أكبر مقارنةً باختبار شامل ضخم ويصعب صيانته ويحاول تنفيذ كل المهام في آنٍ واحد.

المراجِع

• ما هي فوائد توفُّر المباني الليلية؟

التحقق من فهمك