طرق اختبار وحدة المساعد؟

Question

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

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

أيضا من أجل اختبار هذه باستخدام كائن وهمية، سأحتاج إلى تغيير وضوحياتهم من خاصة إلى حماية، هل هذا مرغوب فيه؟

Answer 1

طريقة واحدة هي حذف private ووضع الاختبارات في نفس الحزمة. ثم يمكن الاختبارات استدعاء الأساليب الداخلية ولكن لا يمكن لأحد آخر (= خارج الحزمة).

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

Answer 2

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

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

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

لاحظ أن هذا النهج عزلك من Refactoring: يمكنك تغيير التطبيق دون تغيير جناح الاختبار الخاص بك (نظرا لأن اختبارات الوحدة لكائن المساعد تستمر في المرور حتى عندما يكون كائن المساعد لم يعد جزءا من تطبيق الإنتاج الخاص بك)، وتحصل عبوة نظيفة للتنفيذ والاختبارات الخاصة بها (USECASE: أنت تقرر أن Bozo-Trans هو التنفيذ الخاطئ، ولم يعد ينبغي استخدامه. إذا كان تنفيذ فرز Bozo معزول، فأنت ببساطة إزالتها واختباراتها. ولكن عندما تكون اختبارات تنفيذ فرز Bozo متشابكة مع جميع الاختبارات الأخرى، هناك المزيد من التفكير المعني).

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

Answer 3

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

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

Answer 4

أنا صدمت جدا في بعض الإجابات هنا.

في جوهرها، يقول بعض الناس "لا تختبر الرمز الخاص، لأن ذلك ينتهك نموذج TDD"

اختبار رمز لعنة. افعل ما تحتاج إليه من أجل التأكد من أنه يعمل تماما كما ينبغي.

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

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

ولكن على الإطلاق لا تدع الالتزام الصارم لمنهجية تطويرية في طريق تحسين التعليمات البرمجية.

Answer 5

إذا كنت ترغب في الاختبار المساعد الأساليب التي يمكنك تغييرها من خاص ولكنك قد تفكر في هذا.

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

Answer 6

هذه هي واحدة من تلك الحالات التي أقول فيها المضي قدما وقضاء القواعد.

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

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

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

Answer 7

لديك أساسا 2 خيارات:

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

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

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

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

Answer 8

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

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

Answer 9

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

لقد حددت API العامة في هذه الفئة لسبب ما، أليس كذلك؟ اختبار ذلك. إذا كان يعمل، فإن الفئة تعمل.

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