تحضير اختبارات الوحدة: ما هو المهم أن تضعه في الاعتبار عند العمل على بنية البرمجيات؟ [مغلق

Question

دعنا نقول أنني أبدأ مشروعًا جديدًا ، الجودة هي أولوية قصوى.

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

تعديل : لقد قرأت مقالًا منذ عدة مرات (لا يمكنني العثور عليه الآن) يتحدث عن كيفية فصل رمز التثبيت من الفصول عن سلوكيات الفئات عند اختبار الوحدة. هذا هو نوع نصائح التصميم التي أبحث عنها هنا.

Answer 1

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

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

هذا يعني أيضًا أنه يتعين عليك فرز بناء الكائن الخاص بك بعناية من تنفيذ الكائن الخاص بك. يولد العبارة "الجديدة" الموضوعة في مُنشئ تبعية يصعب استبدالها بسخرية اختبار. من الأفضل تمرير تلك التبعيات عبر حجج المنشئ.

أيضا ، ضع قانون ديميتر في الاعتبار. لا تحفر أكثر من طبقة بعمق في كائن ما ، وإلا فإنك تنشئ تبعيات خفية. استدعاء flintstones.wilma.addchild (الحصى) ؛ يعني ما تعتقد أنه اعتماد على "Flintstones" هو حقًا الاعتماد على كل من "Flintstones" و "Wilma".

Answer 2

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

أوصيك بالتعرف على مبدأ صلب, ، بحيث يمكنك كتابة رمز أكثر قابلية للاختبار.

Answer 3

قد ترغب أيضًا في التحقق من هذين الأسئلة حتى:

• اعتماد اختبار الوحدة
• ماذا يجب أن تكون وحدة

Answer 4

بعض الأفكار العشوائية:

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

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

• اختبار في أدنى مستوى عملي: كلما كانت القطع الصغيرة أكثر ثقة في أن القطع الصغيرة تعمل ، كلما كان من الأسهل الجمع بينها في عمل كامل.

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

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

حظا طيبا وفقك الله!

Answer 5

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