الكتابة الضمنية و TDD

Question

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

يقول منشوره إن TDD يمكن "إبطاء" عند استخدام الكتابة الضمنية لنوع الإرجاع عند اختبار الوحدة طريقة. أيضًا ، يبدو أنه يريد نوع الإرجاع المحدد بواسطة الاختبار من أجل دفع التطوير (وهو أمر منطقي بالنسبة لي).

قد يبدو اختبار وحدة معين مع كتابة ضمنية هكذا:

public void Test_SomeMethod()
{
    MyClass myClass = new MyClass();

    var result = myClass.MethodUnderTest();
    Assert.AreEqual(someCondition, result);
}

لذلك أسئلتي هي:

هل استخدام مساعدة الكتابة الضمنية أو عرقلة اختبارات وحدة الكتابة لـ TDD؟ هل هناك أي شخص يمكنه مشاركة خبرته باستخدام هذه التقنية عند كتابة اختبارات الوحدة؟

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

Answer 1

أرى وجهة نظره ولكني لا أعتقد حقًا أن هذا هو السبب الصحيح لعدم استخدامه var هنا. تذكر أن TDD يعمل بشكل تقريبًا وفقًا لما يلي:

1. اكتب اختبارًا جديدًا.
2. إذا فشل الاختبار في التجميع (ويجب أن يفشل!) ، فاكتب رمزًا كافيًا حتى يجمع الاختبار.
3. تشغيل جميع الاختبارات.
4. إذا فشل الاختبار ، فاكتب رمزًا كافيًا حتى تمر جميع الاختبارات.
5. Refactor.

سواء كنا نستخدم أم لا var سيفشل الاختبار في تجميع أي من الاتجاهين لأن الطريقة قيد الاختبار لن تكون موجودة بعد!. بمجرد أن نبدأ الترميز NewMethod نقاطه هي بدلاً من ذلك.

بدلاً من ذلك ، السبب الصحيح لعدم استخدامه var هنا لأن الرمز لا يعطي أي إشارة إلى نوع من result هو. هذه مسألة رأي ولكن var على ما يرام هنا

var dict = new Dictionary<Foo, List<Bar>>();

ولأنواع مجهولة ولكن ليس هنا

var m = M();

لأنه غير واضح تمامًا دون الذهاب إلى إعلان M (أو باستخدام Intellisense) ما نوع العودة من M هو.

Answer 2

نعم و لا

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

Visual Studio 2010 لديه أ تستهلك الوضع الأول, ، مما يجعلها مثالية وأفضل للتطوير الذي يحركه الاختبار. ستجد حاليًا (في عام 2008 وما قبل) عليك أن تضرب هرب لإخفاء Intellisense.

أما بالنسبة لاستخدام var إنه سكر متصل بحت. يجعل ما يلي أجمل بكثير في رأيي:

var type = new MyType();

من الواضح أن النوع المتغير ، من النوع mytype. var أمر رائع بالنسبة للذهل الأولي ويتبع prinicple من الجفاف - لا تكرر نفسك.

var type = MethodCall();

var result = ReturnResult();

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

Answer 3

من منظور الأدوات ، أقول أنه من أجمل تجنب var. أستخدم Eclipse و Java ، لكنني أعلم أن الامتدادات مثل Coderush و Resharper تقدم العديد من الميزات التي أناقشها هنا. عندما أسمي في الاختبار طريقة غير موجودة بعد ، يمكنني "إصلاحها السريع" لإنشاء الطريقة في الفصل المطلوب. يعتمد نوع الإرجاع للطريقة التي تم إنشاؤها تلقائيًا على سياقها ؛ إذا كنت أتوقع مرة أخرى سلسلة ، فسيكون نوع الإرجاع للطريقة. ولكن إذا كانت المهمة هي VAR (التي لا تملكها Java - ولكن إذا حدث ذلك) ، فلن يعرف IDE ما يكفي لجعل نوع الإرجاع أي شيء آخر غير VAR (أو ربما كائن).

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