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

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

النص البرمجي المطلوب

تتضمن مشاريع الويب عادةً ملف إعداد، وهو ملف 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 مرة واحدة. ضِمن يعني ذلك أن الإعداد التلقائي هو العثور على جميع الملفات التي تنتهي بـ "test.js." أو مشابهة وتشغيلها. استنادًا إلى اخترت عدّاء اختبار، فقد يكون الأمر مختلفًا بعض الشيء.

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

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

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

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

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

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

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

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

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

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

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

إجراء الاختبارات كجزء من عملية الدمج المستمر

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

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

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

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

فاصل عند العودة إلى الإصدار السابق

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

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

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

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

الموارد

• ما هي فوائد إقامة المباني ليلاً؟

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