حدِّد ما تحتاج إلى اختباره وما يمكنك استبعاده.
تناولت المقالة السابقة أساسيات حالات الاختبار وما يجب أن تحتوي عليه. تتعمق هذه المقالة في إنشاء حالات الاختبار من منظور تقني، وتوضح بالتفصيل ما يجب تضمينه في كل اختبار وما يجب تجنبه. سوف تتعلم في الأساس الإجابة عن الأسئلة القديمة مثل "ما الذي يجب اختباره" أو "ما الذي لا يجب اختباره".
الإرشادات والأنماط العامة
وتجدر الإشارة إلى أنّ أنماطًا ونقاطًا محدّدة تمثّل أهمية بالغة، بغض النظر عمّا إذا كنت تجري اختبارات وحدة أو تكاملاً أو اختبارات شاملة. يمكن وينبغي تطبيق هذه المبادئ على كلا النوعين من الاختبار، لذا فهي مكان جيد للبدء.
اعتماد البساطة
عندما يتعلق الأمر بكتابة الاختبارات، أحد أهم الأشياء التي يجب تذكرها هو إبقائها بسيطة. من المهم مراعاة قدرة الدماغ. يشغل رمز الإنتاج الرئيسي مساحة كبيرة، ما يترك مساحة صغيرة للتعقيد الإضافي. هذا صحيح بشكل خاص للاختبار.
في حال عدم توفّر مسافة رأسية أقل، قد تصبح أكثر هدوءًا في جهود الاختبار. لهذا السبب من المهم إعطاء الأولوية لالبساطة في الاختبار. في الواقع، تؤكد أفضل ممارسات اختبار JavaScript ليوني غولدبرغ على أهمية القاعدة الذهبية، حيث يجب أن يبدو الاختبار كمساعد وليس كمعادلة رياضية معقدة. وبعبارة أخرى، ينبغي أن تكون قادرًا على فهم الغرض من الاختبار للوهلة الأولى.
ويجب أن تهدف إلى التبسيط في جميع أنواع الاختبارات، بغض النظر عن مدى تعقيدها. ففي الواقع، كلما كان الاختبار أكثر تعقيدًا، كان تبسيطه أكثر أهمية. تتمثل إحدى طرق تحقيق ذلك في تصميم اختبار مسطح، حيث يتم الاحتفاظ بالاختبارات بسيطة قدر الإمكان، واختبار ما هو ضروري فقط. وهذا يعني أنّ كل اختبار يجب أن يحتوي على حالة اختبار واحدة فقط، وأنّ حالة الاختبار يجب أن تركّز على اختبار وظيفة أو ميزة واحدة محدّدة.
فكر في الأمر من هذا المنظور: ينبغي أن يكون من السهل تحديد الخطأ الذي حدث عند قراءة اختبار فاشل. وهذا هو سبب أهمية الحفاظ على بساطة الاختبارات وسهولة الفهم. حيث يتيح لك ذلك تحديد المشكلات وإصلاحها بسرعة عند ظهورها.
اختبار العناصر التي تستحق ذلك
يشجع تصميم الاختبار المسطح أيضًا على التركيز ويساعد في ضمان أن تكون اختباراتك ذات مغزى. تذكَّر أنّك لا تريد إنشاء اختبارات من أجل التغطية فحسب، بل يجب أن تكون لها دائمًا هدف.
عدم اختبار تفاصيل التنفيذ
تتمثّل إحدى المشاكل الشائعة في الاختبار في أنّ الاختبارات غالبًا ما تكون مصمّمة لاختبار تفاصيل التنفيذ، مثل استخدام أدوات الاختيار في المكوّنات أو الاختبارات الشاملة. تشير تفاصيل التنفيذ إلى الأمور التي لن يستخدمها مستخدمو الرمز الخاص بك أو يطّلعون عليها أو حتى يعرفون عنها عادةً. ويمكن أن يؤدي هذا إلى مشكلتين كبيرتين في الاختبارات: النتائج الموجبة الخاطئة والنتائج الموجبة الخاطئة.
تظهر نتائج سلبية خاطئة عند تعذُّر الاختبار، على الرغم من صحة الرمز الذي تم اختباره. ويمكن أن يحدث ذلك عندما تتغير تفاصيل التنفيذ بسبب إعادة هيكل رمز التطبيق. من ناحية أخرى، تحدث نتائج موجبة خاطئة عند اجتياز الاختبار، على الرغم من أن الرمز الذي يتم اختباره غير صحيح.
أحد حلول هذه المشكلة هو مراعاة الأنواع المختلفة من المستخدمين لديك. قد يختلف المستخدمون النهائيون عن المطوّرين في منهجهم، وقد يتفاعلون مع الرمز بشكل مختلف. عند التخطيط للاختبارات، من الضروري التفكير في ما سيراه المستخدمون أو يتفاعلون معه، وجعل الاختبارات تعتمد على هذه الأشياء بدلاً من تفاصيل التنفيذ.
على سبيل المثال، يمكن أن يؤدي اختيار أدوات الاختيار الأقل عرضة للتغيير في جعل الاختبارات أكثر موثوقية: سمات البيانات بدلاً من أدوات اختيار لغة CSS. لمزيد من التفاصيل، يُرجى الرجوع إلى مقالة "كينت ج". مقالة بعنوان Dodds حول هذا الموضوع، أو يمكنك متابعتنا لأنّنا سننشر مقالة حول هذا الموضوع لاحقًا.
المحاكاة: لا تفقد السيطرة
فالمحاكاة هي مفهوم واسع يستخدم في اختبار الوحدات وفي بعض الأحيان في اختبار التكامل. وهي تتضمن إنشاء بيانات أو مكونات وهمية لمحاكاة التبعيات التي تتحكم بالكامل في التطبيق. وهذا يسمح بالاختبار المعزول.
يمكن أن يؤدي استخدام النماذج التجريبية في اختباراتك إلى تحسين القدرة على التنبؤ وفصل المخاوف والأداء. وإذا كنت بحاجة إلى إجراء اختبار يتطلب مشاركة بشري (مثل التحقق من جواز السفر)، عليك إخفاءه باستخدام وهمي. لكل هذه الأسباب، تعد النماذج أداة قيمة يجب مراعاتها.
في الوقت نفسه، قد يؤثر السخرية على دقة الاختبار لأنها نماذج وليست تجارب المستخدم الحقيقية. لذلك عليك أن تكون حذرًا عند استخدام النماذج التجريبية والملاحظة.
هل يجب أن تقوم بعمل نموذج تجريبي في الاختبارات الشاملة؟
بشكل عام، لا. ومع ذلك، يمكن أن يؤدي الاستهزاء إلى إنقاذ الحياة في بعض الأحيان، لذا لا يمكننا استبعاده تمامًا.
لنفترض أنّك بصدد كتابة اختبار لميزة تتضمّن خدمة مقدّم خدمات دفع تابعة لجهة خارجية. أنّك في بيئة ساندبوكس، ما يعني أنّه لا يتم إجراء أي معاملات حقيقية. للأسف، يحدث خلل في وضع الحماية، مما يؤدي إلى إخفاق اختباراتك. يجب أن يتولى مقدّم خدمات الدفع هذا الإصلاح. ما عليك سوى انتظار حلّ المشكلة من قِبل مقدّم الخدمة.
في هذه الحالة، قد يكون من المفيد أكثر تقليل الاعتماد على الخدمات التي لا يمكنك التحكم فيها. لا يزال من المستحسن استخدام محاكاة تجريبية بعناية في اختبارات الدمج أو الاختبارات الشاملة لأنها تقلل من مستوى الثقة في اختباراتك.
تفاصيل الاختبار: افعل ولا تفعل
إذًا، ما الذي يحتويه الاختبار بشكل عام؟ وهل هناك اختلافات بين أنواع الاختبار؟ لنلقِ نظرة عن كثبٍ على بعض الجوانب المحدّدة الملائمة لأنواع الاختبارات الرئيسية.
ما الذي ينتمي إلى اختبار وحدة جيد؟
يجب أن يتميز اختبار الوحدة المثالي والفعال بما يلي:
- التركيز على جوانب معينة.
- العمل بشكل مستقل.
- تضمين سيناريوهات على نطاق صغير.
- استخدِم أسماء وصفية.
- اتّبِع نمط AAA إذا كان ذلك منطبقًا.
- ضمان تغطية الاختبار الشاملة.
| ما يجب فعله ✅ | لا تفعل ❌ |
|---|---|
| اجعل الاختبارات صغيرة قدر الإمكان. يجب اختبار شيء واحد لكل حالة اختبار. | كتابة الاختبارات على الوحدات الكبيرة. |
| احرص دائمًا على عزل الاختبارات ومحاكاة العناصر التي تحتاج إليها خارج الوحدة. | تضمين المكونات أو الخدمات الأخرى. |
| جعل الاختبارات مستقلة. | الاعتماد على الاختبارات السابقة أو مشاركة بيانات الاختبار: |
| تغطية سيناريوهات والمسارات المختلفة | احصر نفسك بالمسار الصحيح أو بالاختبارات السلبية كحد أقصى. |
| استخدم عناوين اختبارية وصفية، حتى تتمكن من التعرف على موضوع الاختبار على الفور. | يمكنك الاختبار حسب اسم الدالة فقط، مع عدم كونها وصفية بما يكفي كنتيجة لذلك: testBuildFoo() أو testGetId(). |
| احرِص على تغطية جيدة للرموز أو مجموعة أكبر من حالات الاختبار، خاصةً في هذه المرحلة. | اختبر كل فئة وصولاً إلى مستوى قاعدة البيانات (I/O). |
ما الذي ينتمي إلى اختبار دمج جيد؟
ويشارك اختبار الدمج المثالي بعض المعايير مع اختبارات الوحدات أيضًا. ومع ذلك، هناك بعض النقاط الإضافية التي عليك وضعها في الاعتبار. يجب أن يستوفي اختبار الدمج الجيد المتطلبات التالية:
- محاكاة التفاعلات بين المكونات.
- تغطية سيناريوهات العالم الواقعي، واستخدام نماذج أو رموز تجريبية.
- مراعاة الأداء.
| ما يجب فعله ✅ | لا تفعل ❌ |
|---|---|
| اختبِر نقاط التكامل: تأكَّد من أنّ كل وحدة تعمل معًا بشكل متناسق عند دمجها مع بعضها البعض. | اختبِر كل وحدة على حدة، وهذا ما تُستخدَم فيه اختبارات الوحدات. |
| اختبِر سيناريوهات العالم الواقعي: استخدِم بيانات الاختبار المستمدة من بيانات العالم الحقيقي. | استخدِم بيانات اختبارية متكررة يتم إنشاؤها تلقائيًا أو بيانات أخرى لا تعكس حالات الاستخدام على أرض الواقع. |
| استخدم نماذج ونماذج كتيبة للتبعيات الخارجية للحفاظ على التحكم في الاختبار الكامل. | إنشاء اعتماديات على الخدمات التابعة لجهات خارجية، مثل طلبات الشبكة إلى خدمات خارجية. |
| اتّبِع سلسلة إجراءات تنظيف قبل كل اختبار وبعده. | نسيان استخدام تدابير التنظيف داخل الاختبارات، وإلا فقد يؤدي ذلك إلى إخفاقات الاختبار أو نتائج موجبة خاطئة، بسبب عدم وجود عزلة مناسب للاختبار. |
ما الذي ينتمي إلى الاختبار الشامل الجيد؟
يجب أن يتميز الاختبار الشامل الشامل بما يلي:
- تكرار تفاعلات المستخدم.
- تضمين السيناريوهات الحيوية.
- تباعد طبقات متعددة.
- إدارة العمليات غير المتزامنة.
- التأكّد من النتائج
- مراعاة الأداء:
| ما يجب فعله ✅ | لا تفعل ❌ |
|---|---|
| استخدام الاختصارات المستندة إلى واجهة برمجة التطبيقات. مزيد من المعلومات | يمكنك استخدام تفاعلات واجهة المستخدم لكل خطوة، بما في ذلك عنصر الجذب في beforeEach. |
| ننصحك باتّباع سلسلة إجراءات تنظيف قبل إجراء كل اختبار. تعتني بعزل الاختبار أكثر مما تفعله في اختبارات الوحدة والتكامل، لأن هناك احتمالاً أكبر للآثار الجانبية في هذه الحالة. | نسيان تنظيف البيانات بعد كل اختبار. إذا لم تحذف الحالة المتبقية أو البيانات أو الآثار الجانبية، ستؤثر في الاختبارات الأخرى التي يتم إجراؤها لاحقًا. |
| يتعلق بالاختبارات الشاملة باعتبارها اختبارات النظام. وهذا يعني أنّك بحاجة إلى اختبار حزمة التطبيقات بالكامل. | اختبِر كل وحدة على حدة، وهذا ما تُستخدَم فيه اختبارات الوحدات. |
| استخدام الحد الأدنى من السخرية أو عدم السخرية داخل الاختبار. ضع في اعتبارك بعناية إذا كنت تريد محاكاة التبعيات الخارجية. | الاعتماد بشكل كبير على النماذج التجريبية. |
| مراعاة الأداء وعبء العمل عن طريق، على سبيل المثال، عدم الإفراط في الاختبار للسيناريوهات الكبيرة في نفس الاختبار. | يمكنك تغطية مهام سير العمل الكبيرة بدون استخدام الاختصارات. |