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