بداية TDD - التحديات؟حلول؟توصيات؟[مغلق]

StackOverflow https://stackoverflow.com/questions/24965

سؤال

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

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

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

هل كانت مفيدة؟

المحلول

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

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

مع أخذ الفقرة أعلاه في الاعتبار، دعونا نلقي نظرة على أسئلتك:

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

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

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

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

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

نصائح أخرى

من تجربتي الخاصة:

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

  2. لا يوجد 2.انظري هناك!القرود !!!

  3. وحدة هو الطريق للذهاب.

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

ورأيي في هذا هو التالي:

  • إجراء 1+ لعدم اختبار كود إطار العمل، ولكن قد لا تزال بحاجة إلى اختبار الفئات المشتقة من فئات إطار العمل.
  • إذا كان اختبار بعض الفئات/الطرق مرهقًا، فقد يكون ذلك مؤشرًا قويًا على وجود خطأ ما في التصميم.أحاول اتباع مبدأ "فئة واحدة - مسؤولية واحدة، طريقة واحدة - إجراء واحد".بهذه الطريقة ستتمكن من اختبار الطرق المعقدة بشكل أسهل بكثير من خلال القيام بذلك في أجزاء أصغر.
  • +1 لـ xUnit.بالنسبة لجافا، قد تفكر أيضًا في ذلك اختبار.
  • TDD ليس حدثًا واحدًا، بل هو عملية.لذلك لا تحاول تصور كل شيء من البداية، ولكن تأكد من أن كل خطأ موجود في التعليمات البرمجية يتم تغطيته فعليًا عن طريق الاختبار بمجرد اكتشافه.

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

لقد وجدت أن المبادئ الموضحة في ثلاث بطاقات فهرسة لتذكر جوهر TDD بسهولة هو دليل جيد.

على أية حال، للإجابة على أسئلتك

  1. ليس عليك أن تختبر شيئًا "تعرف" أنه سيعمل، إلا إذا كتبته.أنت لم تكتب الأدوية العامة، بل مايكروسوفت هي التي فعلت ذلك ;)
  2. إذا كنت بحاجة إلى القيام بالكثير من أجل الاختبار، فربما يقوم الكائن/الأسلوب الخاص بك بعمل الكثير أيضًا.
  3. تحميل TestDriven.NET لبدء اختبار الوحدة فورًا على Visual Studio الخاص بك (إلا إذا كان إصدار Express)
  4. مجرد اختبار الشيء الصحيح الذي سيحدث.لم تكن يحتاج لاختبار كل ما يمكن أن يحدث بشكل خاطئ:عليك أن تنتظر حتى تفشل اختباراتك من أجل ذلك.

على محمل الجد، فقط تفعل ذلك، المتأنق.:)

أنا لست خبيرًا في TDD بأي حال من الأحوال، ولكن إليكم وجهة نظري:

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

غالبًا ما تكون أطر اختبار xUnit مجانية الاستخدام، لذا إذا كنت من مستخدمي .Net، فاطلع على NUnit، وإذا كانت Java هي الشيء الذي تفضله، فاطلع على JUnit.

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

في رأيي (قد تختلف المسافة المقطوعة):

1- إذا لم تكتبها فلا تختبرها.إذا كتبته ولم يكن لديك اختبار له فهو غير موجود.

3- كما قال الجميع، xUnit مجاني ورائع.

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

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

أفكر دائمًا "ما هو الحد الأدنى من التعليمات البرمجية التي أحتاج إلى كتابتها لإثبات نجاحها في جميع الحالات؟"

خلال العام الماضي، أصبحت مقتنعًا أكثر فأكثر بفوائد TDD.الأشياء التي تعلمتها على طول الطريق:1) حقن التبعية هو صديقك.أنا لا أتحدث عن عكس حاويات وأطر التحكم لتجميع بنيات المكونات الإضافية، بل أتحدث فقط عن تمرير التبعيات إلى مُنشئ الكائن قيد الاختبار.وهذا يعود بأرباح ضخمة في قابلية اختبار التعليمات البرمجية الخاصة بك.2) انطلقت بشغف/حماسة المتحولين وحصلت على إطار ساخر وبدأت في استخدام السخرية في كل ما أستطيع.أدى ذلك إلى اختبارات هشة تطلبت الكثير من عمليات الإعداد المؤلمة، وقد تنهار بمجرد أن أبدأ في إعادة البناء.استخدم النوع الصحيح من الاختبار المزدوج.التزييف حيث تحتاج فقط إلى احترام واجهة ما، أو إرسال البيانات مرة أخرى إلى الكائن قيد الاختبار، أو التزييف فقط عندما تهتم بالتفاعل.3) يجب أن يكون الاختبار صغيرا.اهدف إلى اختبار تأكيد أو تفاعل واحد في كل اختبار.أحاول أن أفعل هذا وفي الغالب أنا هناك.يتعلق هذا بمتانة كود الاختبار وأيضًا بمدى التعقيد في الاختبار عندما تحتاج إلى إعادة النظر فيه لاحقًا.

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

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

"TDD – البدء في التطوير القائم على الاختبار" - لقد تلقيت بعض التعليقات الرائعة حتى الآن وسأكون ممتنًا حقًا لأي شيء تقدمونه يا رفاق.

آمل أن يساعد هذا!:)

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top