الاختبارات الشاملة (End-to-End): متى تفيد ومتى تبطئك فقط

لديك اختبارات الوحدة التي تتحقق من كل دالة. اختبارات التكامل التي تتحقق من استعلامات قاعدة البيانات. اختبارات التعاقد التي تضمن اتفاقيات واجهة برمجة التطبيقات (API). خط الأنابيب أخضر. كل شيء يبدو جيدًا.

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

كل مكون عمل بشكل منفرد. معًا، فشلوا.

هذه هي الفجوة التي تهدف الاختبارات الشاملة (End-to-End) إلى سدها. لكن سد هذه الفجوة يأتي بتكلفة قد تدمر سرعة خط الأنابيب ومعنويات الفريق إذا لم تكن حريصًا.

ما الذي تفعله الاختبارات الشاملة فعليًا

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

فكر في تدفق شراء كامل: تسجيل الدخول، البحث عن المنتجات، الإضافة إلى السلة، إدخال تفاصيل الدفع، تأكيد الطلب، رؤية الإيصال. لا شيء مُحاكى (Mocked). لا شيء مستبدل بنسخة اختبارية. كل جزء من النظام يشارك.

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

التكلفة الحقيقية للاختبارات الشاملة

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

تفشل الاختبارات الشاملة لأسباب لا علاقة لها بكودك. انتهاء المهلة بسبب بطء بيئة الاختبار. بيانات اختبار غير متناسقة متبقية من تشغيل سابق. استنفاد مجموعة اتصالات قاعدة البيانات بسبب الاختبارات المتوازية. تحديد معدل واجهة برمجة التطبيقات الخارجية لطلبات الاختبار الخاصة بك.

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

لهذا لا يمكنك رمي الاختبارات الشاملة على كل شيء. يجب أن تكون جراحيًا بشأن ما تختبره وكيفية تشغيل تلك الاختبارات.

متى تكون الاختبارات الشاملة ضرورية فعليًا

الاختبارات الشاملة مطلوبة عندما لا يمكن التحقق من سيناريو بواسطة أي نوع آخر من الاختبارات. هذا يعني عادةً التدفقات التي تعبر مكونات متعددة في رحلة مستخدم واحدة.

تدفق الدفع هو المثال الكلاسيكي. يمكن لاختبارات الوحدة التحقق من منطق حساب السعر. يمكن لاختبارات التكامل التحقق من حفظ الطلب في قاعدة البيانات. يمكن لاختبارات التعاقد تأكيد تنسيق الطلب إلى بوابة الدفع. لكن لا يمكن لأي من هذه إثبات أن المستخدم الحقيقي يمكنه بالفعل إكمال عملية شراء من البداية إلى النهاية. فقط الاختبار الشامل يمكنه فعل ذلك.

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

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

كيفية تشغيل الاختبارات الشاملة دون إبطاء الجميع

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

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

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

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

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

فيما يلي مثال على تكوين خط أنابيب YAML يقوم بتشغيل الاختبارات الشاملة فقط وفقًا لجدول زمني ليلي أو عند التشغيل يدويًا، مما يحافظ على سرعة خط أنابيب الالتزام الرئيسي:

# azure-pipelines-e2e.yml
# خط أنابيب منفصل للاختبارات الشاملة

trigger: none  # لا يتم التشغيل على كل commit

schedules:
- cron: '0 2 * * *'  # التشغيل ليليًا في الساعة 2 صباحًا
  displayName: اختبارات شاملة ليلية
  branches:
    include:
    - main

resources:
  pipelines:
  - pipeline: mainBuild
    source: main-ci
    trigger:
      branches:
        include:
        - main

jobs:
- job: e2e_tests
  displayName: 'تشغيل الاختبارات الشاملة'
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: |
      echo "بدء مجموعة الاختبارات الشاملة..."
      npm run test:e2e
    displayName: 'تنفيذ اختبارات E2E'

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

قائمة مراجعة عملية

قبل إضافة اختبار شامل جديد، اطرح هذه الأسئلة:

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

إذا كانت الإجابة على السؤال الأول بنعم، لا تكتب الاختبار الشامل. إذا كانت المخاطرة منخفضة، لا تكتبه. إذا لم تكن رحلة حرجة، لا تكتبه.

الخلاصة

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

عدد قليل من الاختبارات الشاملة المختارة جيدًا والتي تعمل بشكل موثوق تساوي أكثر من مائة اختبار غير مستقر لا يثق به أحد.