نصيحة Laravel: كيفية تحسين مجموعة الاختبار الآلي مع نمو مشروعك

تصوير فيكتور تالاشوك على Unsplash

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

هيكلة اختبارات الميزة في مجموعات اختبار منفصلة

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

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

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

تأكد من أنك تستخدم النوع الصحيح من الاختبار وقم ببناء اختباراتك للحصول على تبعيات أقل

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

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

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

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

تجنب الازدواجية في التعليمات البرمجية باستخدام السمات والمصانع ووحدات الماكرو

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

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

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

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

قم بتمديد TestCase الصحيح لاختبارات الوحدة.

إن الجمال في اختبارات الوحدة هو أنها يجب أن تكون دائمًا سريعة حقًا إذا كنت تلتزم بمبادئ عدم لمس قواعد البيانات أو أي خدمات خارجية أثناء كجزء من اختبارات الوحدة الخاصة بك. غالبًا ما تكون قد أجريت اختبارًا للوحدة باستخدام php artisan make: test --unit SomeTest الذي سيوسع اختبار TestCase في مجلد الاختبارات. إذا كنت ترغب في تعزيز اختبارات الوحدة الخاصة بك ولا تتطلب استخدام حاوية خدمة Laravel framework ، يمكنك قضاء وقت جيد خارج اختباراتك.

للقيام بذلك كل ما نحتاجه هو إزالة المرجع لتوسيع Tests \ TestCaseand وبدلاً من ذلك استخدم TestCase PHPUnit \ Framework \ TestCase الأساسي. إذا لم يتطلب اختبارك إطار عمل Laravel ، فسيتم تشغيله بنفس الطريقة ، ولكنه سيكون أسرع لعدم إنشاء حالة التطبيق قبل كل اختبار. ستبدو المكاسب تافهة في مجموعة صغيرة من الاختبارات ولكنها يمكن أن تحقق مكاسب خطيرة لأجنحة اختبار كبيرة بما فيه الكفاية.

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

تجعل أساليب مزود البيانات حالات الاختبار الخاصة بك أكثر قابلية للقراءة

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

كتابة موفر البيانات بسيطة مثل ما يلي:

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

استخدم ملفات PHPUnit.xml مختلفة

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

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

الاستنتاجات

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

أنا بيتر فوكس ، مطور برامج في المملكة المتحدة يعمل مع Laravel من بين أمور أخرى. إذا كنت تريد معرفة المزيد عني ، يمكنك ذلك على https://www.peterfox.me ولا تتردد في متابعتي @ SlyFireFox على تويتر لمزيد من النصائح والبرامج التعليمية الخاصة بـ Laravel.