هذه المقالة ليست دليلًا نظريًا لكتابة الاختبارات وليس كيفية استخدام الأدوات في مجموعة معيّنة ، ولكنها سلسلة من الأسئلة الشائعة ، وأحيانًا كثيرة لم يتم تشكيلها ، والتي سأحاول الإجابة عليها. مصدر هذه الأسئلة هو الزملاء والأشخاص من الجانبين في المقابلات والمعارف ، وستكون الإجابات ذاتية وقصيرة وليست شاملة ، بناءً على مواد الآخرين وتجربتهم. الجمهور المستهدف للمقال هو المطورين الذين يكتبون بنجاح معين ، أو على الأقل يحاولون كتابة الاختبارات ، لكنهم يواجهون صعوبات معينة في كتابتها.
حاولت ألا أرفق بلغة معينة من أجل زيادة وصول القراء ، لكنني سأبدي تحفظًا على الفور بأنني أعمل في نظام PHP البيئي باستخدام PHPUnit ، وبالتالي فإن بعض استنتاجاتي قد لا تكون مناسبة للأنظمة الإيكولوجية الأخرى. عند اختيار الأسئلة والكتابة ، ركزت على العديد من التقارير والمقالات واستخدمتها كمرجع.
سبب الكتابة هو المقال الأخير " PHPUnit. Witterting the Doctrine Entity Manager "بواسطة trawl ، والتي سأناقش بعضها أيضًا.
قائمة الأسئلة:
- لكتابة أو عدم كتابة الاختبارات؟
- وإذا لم يتم تخصيص الوقت للاختبارات؟
- أنواع الاختبار ، وكيفية اختيار؟
- لماذا يصعب عليّ كتابة الاختبارات لفترة طويلة؟
- كيفية اختبار الأساليب الخاصة؟
- كيف تكتب اختبارات الاندماج؟ كيفية اختبار القاعدة؟
- كيفية: التكامل أو وظيفية؟
- ماذا تفعل مع التبعيات الخارجية؟
- كيفية تبسيط التنقل بين الاختبارات وموضوع الاختبار؟
- هل يجب علي استخدام TDD؟
- ماذا يمكن أن تستخدم لتحسين رمز؟
لكتابة أو عدم كتابة الاختبارات؟
رأيت الكثير من الآراء حول هذا الموضوع ، لكنني توصلت إلى رأيي: أحتاج إلى التركيز على احتياجات العمل.
للحصول على قطعة من الشفرة تتم في بضع ساعات على الركبة ، لا تكون هناك حاجة لإجراء اختبارات. من ناحية أخرى ، بالنسبة لمشروع تجاري كبير لمئات من القوى العاملة ، فإن جميع أنواع الاختبارات الشائعة مطلوبة. وكل شيء يقع بين هذين القطبين يجب اعتباره حالة خاصة ، وتقييم تكلفة أنواع معينة من الاختبارات: مع الاختبارات ، يجب أن يكون أقل من دونها. أنا شخصياً أكتب اختبارات الدخان حتى في مشروع CRUD الصغير الذي يدوم أسبوعين ، لأنهم بالفعل يجلبون فوائد على هذه المسافة ويقللون من تكلفة التطوير.
مزايا الاختبار ، لفترة وجيزة وملخص:
- انخفاض كبير في تكلفة إصلاح الخلل بسبب الاكتشاف المبكر.
- تحديد العقود.
- وثائق مستوى منخفض.
- الكشف عن المشاكل المعمارية.
لذلك إذا لم تكن مشاريعك نصوصًا لمرة واحدة من عدة ملفات ، فأنا أوصي بالتأكيد بكتابة اختبارات. لذلك ، يجب إعادة صياغة السؤال من العنوان: "إلى أي مدى يجب أن تكتب الاختبارات ، وأي الاختبارات؟" حول هذا الموضوع كذلك.
وإذا لم يتم تخصيص الوقت للاختبارات؟
هذه مسألة مثيرة للجدل للغاية ، لذلك سأحفظ مرة أخرى أنني أتحدث حصريًا عن رأيي الشخصي ، بينما أحاول القيام بذلك بأقصى دقة ممكنة.
تعتبر اختبارات الكتابة مهمة لا تقل أهمية عن التفكير فيها أو ترميزها أو تصحيحها. الاختبارات هي نفس الرمز مثل منطق الأعمال أو وحدات التحكم. ولكن هل لديك أي أسئلة عنهم؟ لم تقم بتعيين مهمة منفصلة لكتابة وحدة تحكم وعدم تنسيقها مع المديرين؟
ليس من الضروري تخصيص وقت إضافي لكتابة اختبارات الوحدة والتكامل. تتم كتابة الاختبارات كجزء من المهمة الرئيسية. يقرر القائد الفني للمشروع ، بصفته مالك مستودع المشروع والشخص المختص ، كيف وماذا ومع أي نوع من التغطية لكتابة الاختبارات ، مع التركيز على مهام الشركة ، وليس تضخيمها ، ولكن تقليل تكلفة التطوير.
ومع ذلك ، قد يحدث أن العميل لا يؤمن بالاختبارات ويعتقد أنه بمساعدته لا توفر ، ولكن فقط تضيع الوقت. إنه يدفع المال ويحدد الشروط ، وبنفس النجاح ، يمكنه أن يمنعك من استخدام سمة داكنة في IDE الخاص بك أو استخدام خمسة مسافات كمسافة بادئة. وإذا لم تتم مناقشة الشروط أو كانت المناقشة في طريق مسدود ، فاختيارك هو قبول مثل هذه الشروط أو الرفض. مع تقديم المشورة العواقب.
سأبدي تحفظًا على أن هذا الأخير صحيحًا فقط إذا كان بإمكانك كتابة الاختبارات ، وتقييم تكاليفها والعائد المقدر المقدّر. إذا كنت ترغب في معرفة كيفية كتابتها على حساب صاحب العمل في مشروع قصير الأجل ، وكان ضده ، فأنا في صفه.
أنواع الاختبار ، وكيفية اختيار؟
يمكنك إلقاء نظرة على هرم الاختبار الخاص بـ Mike Cohen: كمطورين ، نحن مهتمون بأدنى مستويات الاختبار. يجب بذل أقصى جهد ممكن لاختبار الوحدات ، فهو أرخص (أقصد من الوقت الرخيص الوقت الذي يقضيه في التطوير والدعم) ، ومثل هذه الاختبارات بسيطة للغاية في التنفيذ ، وبسيطة للغاية للتشغيل ، فهي تعمل بسرعة.
ولكن هل وحدة الاختبار قابلة للتطبيق دائمًا أم مستحسن؟ أعتقد أنه بالنسبة لـ CRUD البدائية ، فإن مثل هذه الاختبارات ستستغرق الكثير من الوقت دون تأثير يذكر ولا تضمن أي شيء. حاول اختبار المستودع (المستودع في DataMapper) ثم أجب عن السؤال ، ما الذي قدمه لنا. ولكن بالنسبة لمجموعة متنوعة من الآلات الحاسبة ، سيكون هذا النهج مثاليًا.
حاول دائمًا كتابة اختبارات الوحدات حيثما كان ذلك ممكنًا ، لكن لا تختبر ما هو عديم الفائدة للاختبار.
كيفية اختبار العمل المشترك للواجهة الخلفية والواجهة الأمامية ، إذا كانت هذه مشاريع مختلفة على مداخن مختلفة؟ تمامًا مثل الخلفية وتطبيق الهاتف المحمول: هذا اختبار للنظام ، ويجب أن يكون موضع اهتمام مهندسي ضمان الجودة و DevOps ، وليس المطورين (جيدًا ، فقط إذا لم يكن لديك سكروم حقيقي ، حيث الدور الوحيد المتاح هو مطور مكدس كامل).
بالإضافة إلى ذلك ، يعد اختبار النظام هو الأغلى من حيث التطوير والدعم ، سواء في الوقت المحدد أو في البنية التحتية. يكمن حل المشكلات المتعلقة بهذا بالفعل خارج اختصاص المطورين "الخطيين" ، ويجب أن يقرر المدير الفني وقادة المناطق جنبًا إلى جنب مع رجال الأعمال مسألة تطبيقها ومجلداتها.
لماذا يصعب عليّ كتابة الاختبارات لفترة طويلة؟
في بعض الأحيان يكون من الصعب كتابة الاختبارات لأن الشفرة ليست جاهزة لها. كومة من الغوغاء ، حيث يعطي البعض الآخر ، هي أيضا نتيجة.
لا تستخدم السجلات ، والأحرف المفردة ، والمواقع ، فأنت تعقد حياتك بشكل كبير مع هذا. كان هذا هو الادعاء الرئيسي للمادة التي أشرت إليها أعلاه. استخدم DI ، وقم بتنفيذ المستودعات الضرورية في الخدمات على الفور. مراقبة قانون ديميتر لتجنب سلاسل من mokas. جرب القليل من العمل باستخدام منهجية TDD.
علاج الاختبارات مثل رمز الدرجة الأولى ، مع مراعاة نفس رمز الجودة العالية كما هو الحال في منطق الأعمال. سيؤدي انخفاض جودة رمز الاختبار إلى انخفاض الإنتاجية بمرور الوقت.
كيفية اختبار الأساليب الخاصة؟
لا مفر نحن نختبر عقدًا - الواجهة التي توفرها الوحدة النمطية لوحدات أخرى. نحن لسنا بحاجة لاختبار التنفيذ الداخلي ، يمكن أن تتغير.
ماذا لو كان هناك بعض المنطق المعقد داخل الاختبار ، ويتحول اختبار العقد إلى كمية كبيرة من المدخلات ، حيث يحدث شيء غريب في الداخل؟ من الضروري إعادة تفعيل الكود ، وتوزيعه في فصول مختلفة ، حيث ستصبح هذه الطرق الخاصة عامة ، ويقومون بالفعل بكتابة اختبارات الوحدة. وإذا لم تكن هناك اختبارات ، فسيصعب اكتشاف مثل هذه الأماكن ، مما سيزيد من تكلفة دعم هذا الرمز.
كيف تكتب اختبارات الاندماج؟ كيفية اختبار القاعدة؟
استخدام التجهيزات. استكشف الأدوات الشائعة على مجموعتك.
لا تكتب حزم عالمية كبيرة من التركيبات ، استخدم الحد الأدنى لعددها. إذا كنت بحاجة إلى حالة معينة من الكائنات للاختبارات الخاصة بك ، فلا تقم بإعادة استخدام هذه التركيبات في أماكن أخرى لا تتطلب مثل هذه الحالة ، وإلا فسيكون دعم الاختبار معقدًا: سيؤدي تغييرها لبعض الاختبارات إلى كسر الآخرين وتتطلب وقتًا إضافيًا.
توجد اختبارات تكامل لا تمر بدورة كاملة من طلب إلى استجابة ، ويتم فحص تفاعل الفئات داخل المكون فقط. إذا لم يكن لديهم عمل مباشر مع قاعدة البيانات ، فيمكنك إنشاء مجموعة من البيانات و / أو الصور التي ستدخل في الإدخال. في مثل هذه الحالات ، يمكنك تجنب استخدام التركيبات وتقليل التعقيد ووقت تنفيذ اختبارات التكامل هذه إلى المستوى المعياري.
كيفية: التكامل أو وظيفية؟
اختبار التكامل هو واحد من مستويات الاختبار من حيث العزلة. الاختبار الوظيفي - اختبار الامتثال. تكمن هذه التعريفات في مستويات مختلفة ، ولا يمكنك وضع علامة متساوية بينها ، لكن في الممارسة العملية في المحادثات بين المطورين ، فإنها تعني نفس الشيء ، على الرغم من أن هذا غير صحيح.
ماذا تفعل مع التبعيات الخارجية؟
نحن استبدال التبعيات الخارجية مع moki. ليس فقط لاختبارات الوحدة ، ولكن أيضًا لاختبارات التكامل.
على سبيل المثال ، نستخدم عميل HTTPS للوصول إلى بعض واجهة برمجة التطبيقات من خلال فئة Guzzle. إذا قمت بإنشاء مثيل لمثل هذه الفئة داخل الفصل الدراسي الذي تم اختباره ، فسيكون من الصعب استبداله ، ولكن الحل سيكون بسيطًا للغاية: ننفذ مثل هذا العميل في المُنشئ ، وخلال الاختبار سنقوم باستبداله بموجة.
كيفية تبسيط التنقل بين الاختبارات وموضوع الاختبار؟
يمكن لأدوات التطوير الحديثة تتبع موقع الاختبارات أو فصول الاختبار إذا كنت تستخدم معايير التسمية. لسهولة التصفح ، يمكنك استخدام مجموعة المفاتيح Ctrl + Shift + T في منتجات JetBrains ، بالإضافة إلى ذلك ، إذا لم يكن الاختبار موجودًا ، فستتم مطالبتك بإنشائه وإنشاء إطار سلكي.
في بعض الأحيان ، تحتاج إلى عدة فصول أو طرق اختبار مختلفة لموضوع الاختبار ، في هذه الحالة ، تحتاج إلى مساعدة IDE ، على سبيل المثال ، إضافة تعليق توضيحي يغطي @ في حالة PHPUnit.
هل يجب علي استخدام TDD؟
TDD هي واحدة من منهجيات التطوير التي تكتب فيها الاختبارات بشكل متكرر وضروري أولاً ، ثم الرمز. تجربة هذا الأمر تستحق كل هذا العناء بالتأكيد ، وسوف يعلمك كيفية كتابة التعليمات البرمجية التي تم اختبارها جيدًا. ومع ذلك ، لم يستخدم هذا النهج على نطاق واسع ، لديه مشاكل. إحدى هذه المشاكل هي أنك تكتب اختبارات لن تكتبها باستخدام الطريقة التقليدية. كما يجب دعم مثل هذه الاختبارات وقضاء بعض الوقت عليها والاستفادة منها صغيرة. على سبيل المثال ، اختبارات المستوطنين أو اختبارات الفصول حيث لا يحدث شيء باستثناء مكالمات التبعية. من الأفضل فحص هذه الأماكن عن طريق اختبار التكامل.
ماذا يمكن أن تستخدم لتحسين رمز؟
أدوات التحليل الثابت هي طريقة أخرى لتحسين جودة التعليمات البرمجية الخاصة بك. تتداخل جزئياً مع الاختبارات بالنتيجة ، لكنها غالبًا ما تجد أن الاختبارات لم يتم العثور عليها ، خاصة مع التغطية الضعيفة. ميزتهم بلا شك - ترى النتيجة على الفور في IDE والحصول على ردود الفعل على الفور.
هذا لا يعني أنه يكفي تركهم فقط على IDE ، أنا أوصي بشدة باستخدامهم على CI لرؤية الأخطاء المحتملة وعدم إفساد مثل هذا الكود.
أوصي أيضًا بإضافة دعم أداة التحقق من نمط الشفرة إلى IDE و CI. غالبًا ما يتم إخفاء الأخطاء بين التعليمات البرمجية المكتوبة بلا مبالاة ، وتتيح لك هذه الأدوات العثور على مثل هذه المناطق.
مواد لمزيد من الدراسة