اختبارات كوديشن للخلفية PHP

مرحبا بالجميع! اسمي باشا وأنا مهندس ضمان الجودة لفريق معالجة الطلبات في لامودا. لقد تحدثت مؤخرًا على PHP Badoo Meetup. أريد اليوم تقديم نسخة من تقريري.

سنتحدث عن Codeception ، عن كيفية استخدامه في Lamoda وكيفية كتابة الاختبارات عليه.



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

يتحدث باختصار عن مجموعتنا ، هذا هو PHP + Symfony. هنا وهناك مشاريع قديمة على Zend'e. يتم استخدام PostgreSQL و MySQL كقواعد بيانات ، ويستخدم Rabbit أو Kafka كنظم مراسلة.

لماذا PHP backends؟

نظرًا لأنهم عادةً ما يكون لديهم واجهة برمجة تطبيقات للفروع - فهي إما REST ، في بعض الأماكن يوجد القليل من SOAP. إذا كان لديهم واجهة مستخدم ، فإن واجهة المستخدم هذه تكون أكثر من مساعدة ، والتي يستخدمها مستخدمونا الداخليون.

لماذا نحتاج autotests في Lamoda؟

بشكل عام ، عندما جئت للعمل في Lamoda ، كان هناك شعار مثل: "دعونا نتخلص من الانحدار اليدوي". لن نختبر أي انحدار يدويًا. ونحن عملنا على هذه المهمة. في الواقع ، إليك أحد الأسباب الرئيسية التي تجعلنا نحتاج إلى اختبارات تلقائية - حتى لا نحرك الانحدار باليد. لماذا نحتاج هذا؟ الحق في الافراج بسرعة. حتى نتمكن من دون ألم ، نشر إصداراتنا بسرعة وفي نفس الوقت لدينا نوع من الشبكات من الاختبارات الذاتية التي سيخبروننا ، جيدة أو سيئة. ربما هذه هي أهم الأهداف. ولكن هناك زوجين من المساعدة ، والتي أود أيضا أن أقول عنها.

لماذا نحتاج autotests؟

1. لا تختبر الانحدار بيديك
2. الافراج السريع
3. استخدام وثائق
4. تسريع على متن الموظفين الجدد
5. يتم استخدام الاختبارات التلقائية بسهولة (في بعض الحالات) كوثائق. في بعض الأحيان يكون من الأسهل الدخول في الاختبارات ، ومعرفة الحالات التي يتم تغطيتها ، وكيفية عملها ، وفهم كيفية عمل هذه الوظيفة أو تلك ، وتسريع دخول الموظفين الجدد - المطورين والمختبرين - في مشروع جديد. عندما تجلس لكتابة الاختبارات التلقائية ، يصبح من الواضح كيف يعمل النظام.

حسنًا ، تحدثنا عن سبب حاجتنا إلى اختبارات تلقائية. الآن دعنا نتحدث عن الاختبارات التي نكتبها في لامودا.



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

سوف نتحدث عن المستويات المذكورة أعلاه ، والتي كتبها مطورو واختبار. لنبدأ باختبارات النظام. هذه هي الاختبارات التي تختبر واجهة برمجة التطبيقات (REST أو SOAP) ، أو تختبر بعض منطق النظام الداخلي ، أو الأوامر المختلفة ، أو قوائم انتظار التحليل في الأرنب ، أو تتبادل مع الأنظمة الخارجية. وكقاعدة عامة ، هذه الاختبارات هي ذرية تماما. إنهم لا يفحصون أي سلسلة ، لكنهم يفحصون إجراءً واحداً. على سبيل المثال ، طريقة API واحدة أو أمر واحد. ويقومون بالتحقق من أكبر عدد ممكن من الحالات ، سواء كانت إيجابية أو سلبية.

المضي قدما ، اختبارات E2E. أنا قسمتها إلى 2 أجزاء. لدينا اختبارات تختبر مجموعة من واجهة المستخدم والخلفية. وهناك اختبارات نسميها اختبارات التدفق. انهم اختبار سلسلة - حياة كائن من البداية إلى النهاية.

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

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

"لماذا اخترنا Codeception للتشغيل الآلي للاختبار؟" - ربما تسأل.

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

لماذا الكوديشن؟

1. يمكنك كتابة وتشغيل نفس الاختبارات من أي نوع (وحدة ، وظيفية ، قبول).
2. تم بالفعل حل العديد من الخليع ، وقد تم بالفعل كتابة العديد من الوحدات.
3. في جميع المشاريع ، على الرغم من الاحتياجات المختلفة قليلاً ، ستبدو الاختبارات كما هي.
4. يقترح مفهوم Codeception أن تكتب أي اختبارات في هذا الإطار: الوحدة والتكامل والوظيفة والقبول. وأنت ، على الأقل ، سيتم إطلاقها بالتساوي.
5. Codeception هو معالج قوي بما فيه الكفاية حيث تم بالفعل حل العديد من المشاكل ، العديد من الأسئلة ، العديد من المهام للاختبارات. إذا لم يتم تحديد شيء ما ، فمن المرجح أن تجد شيئًا من الخارج - بعض الوظائف الإضافية لبعض الأعمال المحددة. لا تحتاج إلى كتابة أي أغلفة اختبار لقواعد البيانات ، لشيء آخر. ما عليك سوى أخذ الوحدات النمطية وربطها بـ Codeception والعمل معها.
6. حسنًا ، هذه الإضافة (ربما تكون أكثر ملاءمة للشركات الكبيرة عندما يكون لديك العديد من المشاريع والخدمات) - في جميع المشروعات ، ستبدو الاختبارات زائد أو ناقصة. هذا رائع جدا

سأقول باختصار ما يشبه Codeception ، لأن الكثير منهم عملوا معه.



يعمل Codeception على نموذج ممثل. بعد سحبه إلى المشروع والتهيئة ، يتم إنشاء مثل هذا الهيكل.

لدينا ملفات YML ، فيما يلي - functional.suite.yml ، integration.suit.yml ، unit.suite.yml . أنها تخلق التكوين الاختبارات الخاصة بك. هناك أباء لكل نوع من الاختبارات ، حيث توجد هذه الاختبارات ، يوجد 3 أبا مساعدين:

_ البيانات - لبيانات الاختبار ؛
_ الإخراج - حيث يتم وضع التقارير (XML ، HTML) ؛
_ الدعم - حيث يتم استخدام بعض المساعدين المساعدة والوظائف وكل ما تكتبه في الاختبارات الخاصة بك.

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

الوحدات القياسية

1. PhpBrowser
2. REST
3. ديسيبل
4. المبادرة القطرية
5. AMQP

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

الوحدة الثانية التي نستخدمها هي REST. أعتقد أن الاسم يوضح ما يفعله. لأي تفاعلات http ، يمكنك استخدام هذه الوحدة. يبدو لي أنه يتم حل جميع التفاعلات تقريبًا: الرؤوس وملفات تعريف الارتباط والترخيص. كل ما تحتاجه هو فيه.

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

وحدة Cli ، التي تتيح لك تشغيل أوامر shell و bash من الاختبارات ، ونحن نستخدمها أيضًا.

هناك وحدة نمطية AMQP التي تعمل مع أي وسطاء الرسائل التي تستند إلى هذا البروتوكول. أريد أن أشير إلى أنه تم اختباره رسميا على RabbitMQ. منذ نستخدم RabbitMQ ، كل شيء على ما يرام معه.

في الواقع ، يغطي Codeception ، على الأقل في حالتنا ، 80-85 ٪ من جميع المهام التي نحتاجها. لكن ما زلت مضطرًا للعمل على شيء ما.

لنبدأ مع الصابون.


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


على سبيل المثال ، لدينا متراصة تحتوي على عدة ملفات WSDL ، والعديد من نقاط النهاية SOAP. هذا يعني أنه من المستحيل في الوحدة النمطية Codeception تكوين هذا في ملف yml بحيث يمكن العمل مع العديد.


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


في Codeception ، لا يوجد أي عمل مع Kafka ولا توجد إضافات رسمية أكثر أو أقل من الإضافات الرسمية للعمل مع Kafka. لا يوجد شيء يدعو للقلق ، كتبنا لدينا وحدة.


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


الخلاصة : الوحدات النمطية لـ Codeception سهلة في الكتابة.

المضي قدما. كما قلت ، يحتوي Codeception على وحدة Cli - غلاف لأوامر shell والعمل مع ناتجها.


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

فلماذا نحتاج إلى تشغيل shell في الاختبارات؟

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

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

كيفية تشغيل قذيفة في التطبيق؟

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

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


هناك مشكلة أخرى واجهناها في الاختبارات وهي العمل مع أنظمة الملفات المختلفة. فيما يلي مثال على ما يمكنك وما يجب عليك العمل معه. الثلاثة الأولى هي ذات الصلة بالنسبة لنا. هذه هي Webdav و SFTP ونظام ملفات Amazon.

ماذا تحتاج للعمل مع؟

1. WEBDAV
2. FTP / SFTP
3. AWS S3
4. محلي
5. أزور ، دروببوإكس ، محرك جوجل

إذا كنت تبحث في Codeception ، فيمكنك العثور على بعض الوحدات النمطية لنظام الملفات الأكثر شيوعًا أو أقل تقريبًا.



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

كتبنا لدينا وحدة تسمى Flysystem. تقع على Github في المجال العام وتدعم نظامي ملفات - SFTP و Webdav - وتسمح لك بالعمل مع كليهما باستخدام نفس واجهة برمجة التطبيقات.


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

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


ما هي المهام الرئيسية التي أراها هنا:

1. كيفية طرح قاعدة البيانات للهيكل المطلوب - ديسيبل
2. كيفية ملء قاعدة البيانات مع بيانات الاختبار - ديسيبل ، تركيبات
3. كيفية جعل التحديدات والشيكات - ديسيبل

لكل المهام الثلاث في Codeception ، هناك وحدتان - Db ، التي تحدثت عنها بالفعل ، تسمى أخرى تركيبات.

من بين هاتين الوحدتين و 3 مهام ، نستخدم DB فقط للمهمة الثالثة.

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

سيكون هناك جدول المباريات في شكل صفائف التي يمكن أن تستمر في قاعدة البيانات.

كما قلت ، فإن أول مهمتين نحلها بشكل مختلف بعض الشيء ، والآن سأخبرك كيف نفعل ذلك.

نشر قاعدة البيانات

1. رفع الحاوية باستخدام PostgreSQL أو MySQL
2. نحن لفة جميع الهجرات مع هجرات العقيدة

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

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

النقطة الثانية هي إنشاء بيانات الاختبار. لا نستخدم وحدة التركيبات من Codeception ، بل نستخدم حزمة Symfony للتركيبات.


هناك رابط لها ومثال على كيفية إنشاء تركيبات في قاعدة البيانات.

سيتم بعد ذلك إنشاء تجهيزاتك ككائن في المجال ، ويمكن تخزينها في قاعدة البيانات ، وستكون بيانات الاختبار جاهزة.

لماذا DoctrineFixtureBundle؟

1. أسهل لإنشاء سلاسل من الكائنات ذات الصلة.
2. أقل ازدواجية في البيانات إذا كانت تركيبات الاختبارات المختلفة متشابهة.
3. عمليات تحرير أقل عند تغيير بنية قاعدة البيانات.
4. تعتبر فئات التركيب أكثر بروزًا من الصفائف.

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

تحدثنا عن قواعد البيانات ، دعونا نتحدث قليلا عن moki.

نظرًا لأن هذه اختبارات لمستوى عالٍ بما فيه الكفاية تختبر النظام بأكمله وبما أن أنظمتنا مترابطة للغاية ، فمن الواضح أن هناك بعض التبادلات والتفاعلات. الآن سوف نتحدث عن mokeys على التفاعل بين النظم.

قواعد موك

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

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

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

نحن نستخدم Wiremock للموك ، ويدعم Codeception نفسه ... ، لديه مثل هذه الوظيفة الإضافية Httpmock ، لكننا أحببنا Wiremock أكثر. كيف يعمل؟



يرتفع Wiremock كحاوية Docker منفصلة أثناء الاختبارات ، وجميع الطلبات التي يجب أن تذهب إلى النظام الخارجي تذهب إلى Wiremock.



Wiremock ، إذا نظرت إلى الشريحة - يوجد مربع من هذا القبيل ، "طلب التعيين" ، يحتوي على مجموعة من هذه التعيينات التي تقول إنه في حالة وصول مثل هذا الطلب ، يتعين عليك تقديم إجابة من هذا القبيل. كل شيء بسيط للغاية: جاء طلب - تلقى وهمية.

يمكن إنشاء الموكس بشكل ثابت ، ثم الحاوية ، عندما يرتفع Wiremock بالفعل ، ستكون هذه المكسرات متاحة ، ويمكن استخدامها في الاختبار اليدوي. يمكنك إنشاء ديناميكي ، مباشرة في التعليمات البرمجية ، في نوع من الاختبار.

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



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

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

ماذا نستخدم؟



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

Make يُستخدم للأوامر الداخلية ، ويستخدم Bamboo كـ CI.

كيف تبدو تجربة اختبار CI؟



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

يتم رفع كل هذه البيئة بمساعدة Docker Compose. هو في CI ، على همز أن جميع الحاويات تدور تحت Kubernetes. ثم قم بإجراء الاختبارات وتشغيلها.

كم من الوقت يستغرق كل شيء؟

كل هذا يتوقف على الخدمة المحددة ، ولكن كقاعدة عامة ، رفع البيئة قبل إجراء الاختبارات هو 5-10 دقائق ، الاختبارات - من 6 إلى 30 دقيقة.



سأحذر على الفور من هذا السؤال بينما تتابع كل الاختبارات في موضوع واحد.

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

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

بطبيعة الحال ، عندما نطرح الإصدار. على الإصدار ، يجب أن تمر جميع الاختبارات.

في النهاية ، أود أن أقول شيئًا ملهمًا - كتابة الاختبارات ، والسماح لها أن تكون خضراء ، واستخدام Codeception ، وجعل moki. أعتقد أنكم جميعًا تفهمون هذا تمامًا.