هل يؤثر الإعداد/التفكيك على إمكانية صيانة الاختبار؟

Question

يبدو أن هذا أثار القليل من المحادثة سؤال آخر واعتقدت أنه يستحق الدوران في سؤاله الخاص.

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

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

• جيمس نيوكيرك
• جاي فيلدز, [2]

في الواقع ، قامت Xunit.net بإزالتها من الإطار تمامًا لهذا السبب بالذات (على الرغم من أن هناك طرق للتغلب على هذا القيد الذي فرضته على نفسها).

ما كانت تجربتك؟هل يؤذي الإعداد/التفكيك أو يساعد في اختبار قابلية الصيانة؟

تحديث:هل ستحدث المزيد من التركيبات الدقيقة مثل تلك المتوفرة في JUnit4 أو TestNG (@BeforeClass، @BeforeGroups، وما إلى ذلك) فرقًا؟

Answer 1

الأغلبية (إن لم يكن كلها). صالح يمكن كتابة استخدامات أساليب الإعداد والتفكيك كطرق مصنع تسمح بالتجفيف دون الدخول في مشكلات يبدو أنها تعاني من نموذج الإعداد/التفكيك.

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

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

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

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

Answer 2

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

على أي حال، إذا فشل اختبار واحد، فقد ذهبت إلى المرحلة التالية، في محاولة لدخول المستخدم نفسه من الاختبار الأول في DB، وانتهاك قيد التفرد، والفشل متتالية من هناك. نقل إنشاء المستخدم / حذف المستخدم في [برنامج الإعداد] [الإعداد | الدموع] سمحت لنا طرق لرؤية الاختبار الواحد الذي فشل دون كل شيء يسير في كل شيء، وجعل حياتي أسهل بكثير وأقل سرعة.

Answer 3

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

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

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

Answer 4

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

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

بعد الأمثلة في "اختبار مدفوع", ، تأتي طريقة الإعداد حول من إزالة الازدواجية في حالات الاختبار.

Answer 5

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

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

اختبارات التكامل والاختبارات الوظيفية (والتي تستخدم في كثير من الأحيان إطار xunit) من المرجح أن تحتاج إلى الإعداد والدموع.

النقطة التي يجب تذكرها هي التفكير تركيبات, ، ليس فقط جافة.

Answer 6

ليس لدي مشكلة في إعداد اختبار وأساليب المسيل للدموع في حد ذاته.

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

تتخلص XUNIT.NET من الإعداد / الدموع، لأنه ينشئ كائنا جديدا لكل اختبار يعمل. في جوهرها، يصبح المنشئ طريقة الإعداد، ويصبح النهائي طريقة الدموع. لا يوجد (مستوى الكائن) الذي عقد بين الاختبارات، والقضاء على هذا ناقل الخطأ المحتمل.

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

Answer 7

لم يكن لدي وقت لقراءة كل ما نشرته، لكنني على وجه الخصوص أحب هذا التعليق:

يتم إجبار كل اختبار على القيام بتهيئة ما يجب تشغيله.

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

Answer 8

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

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

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

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

أحب أن أسمع كيف يشعر الآخرون حيال ذلك.

Answer 9

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