قصة كيف قمنا بتسريع الاختبارات 12 مرة

قالوا إن تسريع الاختبارات.

والآن ، لقد مر ما يقرب من نصف عام ، عندما نعيد كتابة اختباراتنا الوظيفية القديمة غير المستقرة والطويلة وغير المستقرة وننتقل إلى اختبارات سريعة مستقلة عن المكونات. لذلك ، حان الوقت للمشاركة :)

بالنسبة لأولئك الذين لا يعرفون ، اختبارات المكونات هي اختبارات معزولة تمامًا عن البيئة العالمية وتسمح لك باختبار حالات معينة لا يمكن أن يغطيها اختبار الوحدة.

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

في الواقع ، في هذه الحالة ، تعد اختبارات الضرر أكثر من جيدة ، ولكن التخلص منها و "تسجيلها" في الاختبارات أبعد ما يكون عن الخيار الأفضل :) ثم ، تم تنظيم فريق صغير صغير من قبل قائد الفريق:

1. Timlida
2. المطور الخلفية
3. مهندس ضمان الجودة
4. المشرف

بعد أن تعاوننا بسرعة ، قسمنا مهامنا وكان أحدها تهيئة بيئة لكتابة اختبارات المكونات. وهكذا بدأت رحلتي.

في بداية التطوير ، كان لدينا أكثر من 140 اختبارًا وظيفيًا تم إجراؤها في عدة سلاسل محادثات في بيئات مختلفة (Frontend ، Mobile ، Backend) واستغرقوا حوالي 5-7 دقائق ؛ غالبًا ما كان عليها أيضًا إعادة تشغيلها من أجل تحقيق بناء أخضر. ولم تعد هذه الاختبارات قائمة بسبب رمز مكتوب جديد ، ولكن بسبب مشاكل في البيئة ، أي في مكان لم تستجب فيه واجهة برمجة التطبيقات ، أو في مكان ما سقطت فيه الخدمة الدقيقة ، وما إلى ذلك. أوقف هذا عمل القسم بأكمله ، حيث بدأت التجمعات كل 5-10 دقائق تقريبًا: شخص ما أعيد تجميعه ، شخص دفع رمزًا جديدًا ...

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

http-api-mock هو خادم وهمية خفيف الوزن وخالي من التثبيت مكتوب في Go مع وثائق جيدة.

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

يمكن لفئة المساعد الأساسي إنشاء إعلان على شكل ملف json في دليل التكوين لخادمنا الوهمي ، وإعطاء الإعلان المطلوب عن طريق المعرّف ، إلخ. تقريبا API.

بقية السحر ينتظرنا أكثر - الآن بقي فقط لإعداد خطة التجميع في الخيزران. حتى تمر اختباراتنا الآن من خلال CI & CD.

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

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

# Delete/Create network docker network rm mock-kolesa-net; docker network create --subnet=IP_ADDR/24 --gateway IP_ADDR_GATEWAY mock-kolesa-net; # Docker run http-mock-kolesa docker run \ --rm \ --name http-mock-kolesa -d \ -v ${CONFIG}/config/:/config \ -v ${CONFIG}/data/:/data \ --user $(id -u):$(id -g) \ --net mock-kolesa-net \ --ip IP_ADDR\ local-docker-hub.kolesa-domain.org:7979/build/http-mock-kolesa; 

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

مر الوقت ، أعيدت كتابة الاختبارات ، وتحول 140 اختبارًا وظيفيًا إلى 103 اختبارات للمكونات ، والتي تعمل بالتوازي في 30 ثانية تقريبًا.

من الايجابيات

ذكيا جدا . نظرًا لحقيقة أنهم مستقلون تمامًا عن بيئة الاختبار ، لا يتعين عليهم الذهاب بعيدًا للحصول على البيانات.

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

سهل الكتابة . في الواقع ، في عملية إعادة الكتابة ، تم تحديد الكثير عن طريق نسخ الرمز من الاختبار الوظيفي القديم إلى المكون الجديد وتجهيز نقاط النهاية له في خادم Mock.

من السلبيات

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

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

النتائج:

الاختبارات
كان: 140+ اختبار وظيفي = 5-7 دقائق.
الآن: 103 اختبار مكون = 30 ثانية.

بناء الاستقرار
قيل: كل تجمع ثالث سقط بسبب أي مشاكل.
أصبح: يسقط فقط عندما يكسر المطور منطق طريقة ما.

في الخطط المستقبلية ، يتعين علينا إعادة كتابة اختبارات القبول (GUI) - أيضًا تشغيلها داخل الحاوية وعزلها عن بقية البيئة.