تميل الأسماء التي تُمنح لأنواع مختلفة من الاختبارات إلى أن يكون لها موضوعات مشتركة عبر قواعد التعليمات البرمجية، ولكن ليس لها تعريفات صارمة بشكل خاص. تقدم هذه الدورة بعض الإرشادات حول معنى كل نوع من أنواع الاختبار، لكن قد توفر موارد أخرى تعريفات مختلفة.
في الصفحات السابقة، كانت هناك أمثلة لكل من اختبارات الوحدات واختبارات المكوّنات (في المثال الذي ذكرناه، بالرجوع إلى مكوّن React). ويمكننا التركيز على هذين النوعين من العناصر في هرم الاختبار (أو أي شكل آخر)، لأنّ لكل منهما مستوى تعقيد منخفض وسريع في التنفيذ، ولكن قد لا يكون فيهما فائدة كبيرة مثل اختبار الدمج الأكثر تعقيدًا.
الأنواع الشائعة من الاختبارات
اختبارات الوحدات
اختبارات الوحدات هي الأصغر في النطاق. يتم استخدامها لاختبار أجزاء صغيرة من الرمز، أو التعليمات البرمجية عديمة الحالة البحتة، بطريقة رياضية تقريبًا: إذا قمتُ بتقديم التعليمة البرمجية بالمدخلات X وY وZ، فإن مخرجاتها يجب أن تكون A وB وC.
لا يكون للرمز البرمجي الذي يتضمّن اختبارات الوحدات عادةً تبعيات خارجية، مثل الجلب من شبكة أو استخدام أي وظائف أو مكتبات أخرى ضمنيًا. إنها عقدة شجرة من التعليمات البرمجية يمكنك "قطعها" واختبارها من تلقاء نفسها.
تميل اختبارات الوحدات إلى أن تكون سريعة في الكتابة والتنفيذ، إلا أنه من الممكن دائمًا ألا يعطي اختبار الوحدات الصغيرة من التعليمات البرمجية معلومات مفيدة. غالبًا ما يعني عدم تفاعل وحدة التعليمات البرمجية مع التعليمات البرمجية الأخرى أنه من الأفضل إجراء الاختبار على مستوى أعلى لتقليل المخاطر.
اختبارات المكونات
بالنسبة إلى مطوّري البرامج على الويب، يكون اسم "المكوِّن" زائدًا عن الحد، ويعني هذا عادةً مكوِّنًا مرئيًا للمستخدم، مثل مكوِّن React أو مكوّن ويب. تعريفه الأكثر عمومية هو جزء عمل قابل للاختبار، على سبيل المثال، فئة ذات تبعيات خارجية. ليتم اختباره بشكل فعال، يجب أن يتم محاكاة تبعياته أو تخطيها.
ولأنّ ممارسات تطوير الويب الحديثة تستند إلى مفهوم المكوِّن، تُعدّ اختبارات المكوّنات طريقة عملية للتفكير في الاختبار: على سبيل المثال، قد تقرر أنّ كل مكوِّن يحتاج إلى اختبار. من السهل أيضًا متابعة اختبارات المكونات في السياقات التي يدعي فيها مطور واحد أو فريق صغير ملكية واضحة للمكون. ومع ذلك، قد يكون من الصعب محاكاة التبعيات المعقدة.
اختبارات الدمج
تميل هذه الأدوات إلى اختبار مجموعة صغيرة من المكونات أو الوحدات أو الأنظمة الفرعية أو الأجزاء الأخرى المفيدة من الرمز معًا لضمان عملها بشكل صحيح. هذا تعريف غامض للغاية. وبالنسبة إلى مطوري الويب، تخيل أن التعليمة البرمجية التي تختبرها ليست نسخة إنتاج حقيقية لموقعك (أو حتى مغلقة)، ولكنها لا تزال تربط بين مكونات عديدة ذات صلة بنظامك.
قد يشمل ذلك حتى التبعيات "الحقيقية"، مثل قاعدة بيانات خارجية في وضع الاختبار، بدلاً من وهمية خالصة. على سبيل المثال، بدلاً من أن تقول إن query() ستعرض دائمًا المدخلين نفسهما، يمكن أن يؤكد اختبار الدمج الذي تُجريه أن قاعدة بيانات الاختبار تحتوي على شيء آخر. البيانات نفسها أقل أهمية، لكنك
تختبر الآن إمكانية الاتصال بقاعدة بيانات والاستعلام عنها بنجاح.
من الممكن كتابة اختبارات دمج بسيطة نسبيًا لها آثار واسعة النطاق يمكن التحقّق منها باستخدام التأكيدات، لأنّ إجراء واحد مرتبط بمكوّنات مختلفة يمكن أن يؤدي إلى سلسلة من التأثيرات القابلة للقياس.
لهذا السبب، يمكن أن تُظهر اختبارات التكامل بشكل فعّال أنّ النظام المعقد
يعمل على النحو المطلوب. ومع ذلك، قد يكون من الصعب كتابتها وصيانتها،
ويمكن أن تؤدي إلى تعقيد لا داعي له. على سبيل المثال، تؤدي كتابة
FakeUserService في اختبار دمج إلى إضافة مطلب تنفيذ UserService على كلٍّ من الفريق
وRealUserService.
اختبارات الدخان
هذه هي اختبارات يجب أن تكمل بسرعة كبيرة وتحدد ما إذا كانت قاعدة التعليمات البرمجية لديك في حالة معقولة. من الناحية العملية، يعني هذا إلى حد كبير إجراء اختبارات بسيطة على التعليمات البرمجية التي لها تأثيرات واسعة النطاق على تجربتك.
على سبيل المثال، في تطبيق ويب كبير تم تسجيل الدخول إليه، قد يضمن ذلك عمل نظام تسجيل الدخول والمصادقة، لأنه بدونه يصبح التطبيق غير قابل للاستخدام ولن تكون هناك حاجة إلى إجراء اختبارات إضافية.
يمكن أن تكون اختبارات الدخان مرشحًا جيدًا لإجرائها ضمن النص البرمجي test في package.json في قاعدة رموز كبيرة. يمكن أن يكون الاختبار اليدوي أيضًا نوعًا من اختبار الدخان.
اختبارات الانحدار
اختبار الانحدار هو نوع من اختبار الدخان الذي يضمن استمرار عمل الميزات الحالية، أو عدم إعادة تقديم الأخطاء القديمة، بعد طرح إصدار جديد أو تطوير ميزات أخرى.
ويرتبط هذا بمفهوم التطوير القائم على الاختبار (TDD). ويتم احتساب حالات الاختبار المكتوبة بهدف عرض خطأ بشكل صريح، وتُستخدم لاحقًا لضمان إصلاح الخطأ، كحالات اختبار انحدار، لأنّها يجب أن تمنع تكرار ظهور الخطأ نفسه.
ومع ذلك، قد يمثل اختبار الانحدار مشكلةً دون حل رائع. إنه مصطلح غالبًا ما يشار إليه باحتياجات العمل: مع تطوير الميزات، من المهم عدم تعطل الميزات القديمة. من المفترض أن يكون قاعدة التعليمات البرمجية المُختبَرة جيدًا قادرة على الحفاظ على ذلك، لكن قواعد الرموز البرمجية الحقيقية لا ترقى دائمًا إلى هذا المستوى المثالي. وسيتم تناول هذا بشكل أكبر في أقسام مستقبلية.
اختبارات مرئية
يشمل الاختبار المرئي أخذ لقطات شاشة أو مقاطع فيديو لحالة موقع ويب من أجل فحص حالة جيدة معروفة (مثل لقطة شاشة سابقة) مقابل عملية الاختبار الحالية. تتطلب، بطبيعتها، تشغيل متصفح حقيقي بحيث يمكنه عرض HTML وCSS وأجزاء أخرى من الموقع.
بدلاً من إجراء اختبارات مرئية على الاختبارات الشاملة التي تشغِّل قاعدة الرموز بالكامل، قد يكون من المفيد إنشاء "أدوات" HTML تعرض مكونات معيّنة فقط، لا سيما في أحجام الشاشات المختلفة، ما يؤدي إلى تشغيل واجهات مستخدم سريعة الاستجابة. هذا أكثر تعقيدًا من استخدام JSDOM فقط أو أطر عمل مماثلة.
يمكن أن يكون فشل الاختبارات المرئية إشارة جيدة لأنواع أخرى من العطل. ومع ذلك، قد لا تجتاز واجهات المستخدم المعقدة الاختبارات المرئية لأسباب لا تتعلق بالميزات التي تحاول اختبارها، مثل الميزات الجديدة الأخرى التي تغيّر مظهر واجهة المستخدم، أو حتى عرض الرموز التعبيرية لإصدار جديد من نظام التشغيل بشكل مختلف عن الإصدارات السابقة.
اختبارات شاملة
غالبًا ما تكون الاختبارات الشاملة في الجزء العلوي من التسلسل الهرمي للاختبار. فهي تصف التفاعل مع تطبيق الويب أو موقع الويب بالكامل، ربما يتمحور حول ميزة معينة، وعادةً ما يتم تشغيلها داخل متصفح يتحكم فيه وكيل مثل WebdriverIO أو Selenium أو Puppeteer، والذي يمكنه تشغيل قاعدة الرموز الخاصة بك أكثر أو أقل أثناء نشرها في مجال الإنتاج (على الرغم من أنّها غالبًا ما يتم عرضها على مضيف محلي).
وحسب موقعك الإلكتروني، قد يتضمن ذلك تسجيل الدخول كمستخدم تجريبي وتنفيذ إجراءات رئيسية والتأكّد من أنّ موقعك أو نظامك في الحالة الصحيحة. سنتناول المزيد من الأمثلة على هذا النوع من الاختبارات في أقسام إضافية، لأنها قد تكون قوية للغاية، ولكن يصعب الحفاظ عليها في بعض الأحيان.
يمكن أن تتضمن بعض الأساليب لتبسيطها تقليل نطاقها أو محاكاة مكونات معينة عند الاقتضاء. على سبيل المثال، إذا كان المستخدمون بحاجة إلى تسجيل الدخول إلى موقعك الإلكتروني، لكنّ الميزة التي تختبرها ليست ميزة تسجيل الدخول، يمكنك وضع علامة لبيئات الاختبار تتيح لوحدة التحكّم في الاختبار العمل كمستخدم بدون تسجيل الدخول أو إنشاء ملفات تعريف الارتباط المرتبطة بها.
على الرغم من أن الاختبارات الشاملة يمكن أن تكون طرقًا قوية جدًا للاختبار عبر أقسام واسعة من قاعدة التعليمات البرمجية في وقت واحد، فإن مثل هذه الاختبارات الواسعة النطاق تكون غير مستقرة أو غير موثوقة بسبب اعتمادها على الأنظمة الخارجية. ويمكنهم أيضًا في كثير من الأحيان ترك الكثير من بيانات الاختبار في قاعدة البيانات لديك إذا قام كل اختبار مثلاً بإنشاء إدخال أو تعديله. قد يؤدي تجميع بقايا البيانات مثل هذه إلى صعوبة تحديد كيفية فشل الاختبار.
اختبار واجهة برمجة التطبيقات
يمكن أن تشير اختبارات واجهة برمجة التطبيقات إلى تأكيد سلوك واجهات برمجة التطبيقات التي يوفّرها برنامجك، أو الوصول إلى واجهات برمجة تطبيقات حقيقية (ربما تكون مباشرة) لتأكيد سلوكها. وفي كلتا الحالتين، يميل هذا إلى اختبار التجريدات بين الأنظمة، أي كيفية تواصلها مع بعضها في النهاية، بدون دمجها معًا كما هو الحال في اختبار الدمج.
يمكن أن توفّر هذه الاختبارات مقدمة أساسية لاختبار الدمج بدون تحمّل تكاليف تشغيل الأنظمة التي تختبر الاتصالات بينها. ومع ذلك، يمكن أن تكون اختبارات الأنظمة الواقعية غير مستقرة.
الأنواع الأخرى
هناك أساليب أخرى متنوعة للاختبار قد تكون مفيدة، حسب مصدرك. في ما يلي الأمثلة المثيرة للاهتمام:
- الاختبار اليدوي.
- يؤكد اختبار القبول، وهو نوع من الاختبارات اليدوية التي يشيعها أجايل، أن المنتج "يلبي احتياجات المستخدم".
- يشير اختبار الفوضى إلى إدخال بيانات عشوائية لمعرفة ما يحدث، والتأكد من عدم تعطل الموقع إذا تم إدخال بيانات سيئة.
- وتحاكي اختبارات الإخفاقات عمدًا حالات الفشل في الأنظمة المعقدة، مثل حالات تعطُّل الشبكة، للتأكد من أن الرمز البرمجي الذي يخضع للاختبار يستجيب بطريقة خاضعة للرقابة.
- يؤكد اختبار الإصدار أنّه يمكن إنشاء عناصر إصدار قاعدة التعليمات البرمجية من خلال التأكّد من توفّرها أو محتواها. وقد يكون هذا النوع من الاختبارات مفيدًا في التحقّق من نتائج نظام إدارة محتوى معقّد.
تغطية الرمز
من الممكن قياس النسبة المئوية للرمز الذي يتم اختباره بواسطة اختبارات آلية، والإبلاغ عن ذلك كإحصاء بمرور الوقت. ولا ننصح باعتماد تغطية كاملة للرموز البرمجية بنسبة% 100، لأنّ ذلك قد يؤدي إلى تحمّل أعباء غير ضرورية إلى جانب إجراء اختبارات مبسّطة أو سيئة التصميم لا تتناول حالات الاستخدام الرئيسية بشكل مفصّل.
يمكن أن تكون التغطية نفسها أداة مفيدة أيضًا عند كتابة اختباراتك أو العمل عليها، خاصةً اختبارات التكامل. من خلال عرض نسبة مئوية أو تقسيم سطر بسطر للتعليمة البرمجية التي يتم اختبارها من خلال اختبار واحد، يمكنك الحصول على نظرة ثاقبة حول المفقود أو ما يمكن اختباره بعد ذلك.
المراجِع
التحقق من فهمك
أي مما يلي يعتبر أنواعًا معروفة من الاختبارات؟