TDD - مشاكل المبتدئين والتعثر

Question

على الرغم من أنني كتبت اختبارات الوحدة لمعظم الكود الذي قمت به ، فقد حصلت مؤخرًا على نسخة من TDD بواسطة Kent Beck. لطالما أعربت عن أسفه لبعض قرارات التصميم التي اتخذتها منذ أن منعت التطبيق من "قابلاً للاختبار". قرأت من خلال الكتاب ، وبينما يبدو بعضه غريبًا ، شعرت أنه يمكنني إدارته وقررت تجربته في مشروعي الحالي وهو نظام عميل/خادم في الأساس حيث تتواصل القطعتان. USB. واحد على الأداة والآخر على المضيف. التطبيق في بيثون.

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

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

1. يستخدم Kent Beck قائمة يضيفها وتخرج منها لتوجيه عملية التطوير. كيف تصنع مثل هذه القائمة؟ في البداية كان لدي بعض العناصر مثل "يجب أن يبدأ الخادم" ، ويجب إحباط الخادم إذا لم تكن القناة متوفرة "وما إلى ذلك ، لكن تم خلطها وأخيراً الآن ، إنها مجرد شيء مثل" يجب أن يكون العميل قادرًا على الاتصال بالخادم "(وهو ما بدء تشغيل الخادم اللطيف وما إلى ذلك).
2. كيف تتعامل مع إعادة الكتابة؟ لقد اخترت في البداية نظامًا مزدوجًا نصفًا يعتمد على الأنابيب المسماة حتى أتمكن من تطوير منطق التطبيق على الجهاز الخاص بي ثم إضافة جزء اتصال USB لاحقًا. لقد تحركوا لتصبح شيئًا يعتمد على المقبس ثم نقله من استخدام مآخذ أو الخام إلى استخدام وحدة Python Socketserver. في كل مرة تتغير فيها الأمور ، وجدت أنه كان علي إعادة كتابة أجزاء كبيرة من الاختبارات التي كانت مزعجة. اعتقدت أن الاختبارات ستكون دليلًا ثابتًا إلى حد ما أثناء تطوري. شعروا فقط مثل المزيد من التعليمات البرمجية للتعامل معها.
3. كنت بحاجة إلى عميل وخادم للتواصل عبر القناة لاختبار كلا الجانبين. كان بإمكاني السخرية من أحد الجانبين لاختبار الآخر ولكن بعد ذلك لن يتم اختبار القناة بأكملها وأخشى أن أفتقد ذلك. هذا ينتقص من إيقاع الأحمر/الأخضر/Refactor بأكمله. هل هذا مجرد نقص في الخبرة أم أفعل شيئًا خاطئًا؟
4. تركني "Fake It Till You Lek" مع الكثير من التعليمات البرمجية الفوضوية التي قضيتها لاحقًا الكثير من الوقت لإعادة التنظيف والتنظيف. هل هذه هي الطريقة التي تعمل بها الأمور؟
5. في نهاية الجلسة ، أصبح لدي الآن موكلي وخادمي يعملان بحوالي 3 أو 4 اختبارات وحدة. استغرق الأمر مني حوالي أسبوع للقيام بذلك. أعتقد أنه كان بإمكاني القيام بذلك في يوم واحد إذا كنت أستخدم اختبارات الوحدة بعد طريقة الكود. فشل في رؤية المكسب.

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

ملاحظة: يرجى إعلامي إذا كان هذا يجب أن يكون ويكي المجتمع وسأضع علامة عليه على هذا النحو.

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

تحديث 1: ممارسة الممارسة!

Answer 1

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

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

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

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

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

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

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

تركني "Fake It Till You Lek" مع الكثير من التعليمات البرمجية الفوضوية التي قضيتها لاحقًا الكثير من الوقت لإعادة التنظيف والتنظيف. هل هذه هي الطريقة التي تعمل بها الأمور؟

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

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

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

Answer 2

1. يستخدم Kent Beck قائمة ... أخيرًا الآن ، إنه مجرد شيء مثل "يجب أن يكون العميل قادرًا على الاتصال بالخادم" (الذي يتم تشغيله الخادم اللاحق وما إلى ذلك).

في كثير من الأحيان ممارسة سيئة.

اختبارات منفصلة لكل طبقة منفصلة من الهندسة المعمارية جيدة.

تميل الاختبارات الموحدة إلى حجب القضايا المعمارية.

ومع ذلك ، اختبار الوظائف العامة فقط. ليس كل وظيفة.

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

2. كيف تتعامل مع إعادة الكتابة؟ ... وجدت أنه كان علي إعادة كتابة أجزاء كبيرة من الاختبارات.

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

و

نعم ، تغيير معماري كبير يعني تغيير اختبار كبير.

و

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

3. كنت بحاجة إلى عميل وخادم للتواصل عبر القناة لاختبار كلا الجانبين. يمكنني أن أسخر من أحد الجانبين لاختبار الآخر ولكن بعد ذلك لن يتم اختبار القناة بأكملها ...

هناك اختبارات الوحدة. مع السخرية.

هناك اختبارات تكامل ، والتي تختبر كل شيء.

لا تخلطهم.

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

وتحتاج إلى القيام بالأمرين.

4. تركني "المزيفة حتى تصنعها" مع الكثير من الكود الفوضوي الذي قضيته لاحقًا الكثير من الوقت لإعادة التنظيف والتنظيف. هل هذه هي الطريقة التي تعمل بها الأمور؟

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

لقد وجدت أن إعادة البناء أمر جيد وتصميم مقدما صعب للغاية. ربما يكون ذلك لأنني كنت أتعامل مع ما يقرب من 40 عامًا وعقلي يلبس.

5. فشل في رؤية المكسب.

جميع العباقرة الحقيقية تجد أن الاختبار يبطئهم.

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

إذا كنت لا تحتاج دليل - إثبات أن الرمز الخاص بك يعمل ، لا تحتاج إلى اختبار.

Answer 3

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

أبدأ باختيار أي شيء قد أتحقق منه. في مثالك ، اخترت "يبدأ الخادم".

Server starts

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

Configured server correctly
Server starts

على الرغم من ذلك ، على الرغم من أن "الخادم يبدأ" يعتمد على "الخادم الذي تم تكوينه بشكل صحيح" ، لذلك أقوم بتوضيح هذا الرابط.

Configured server correctly
Server starts if configured correctly

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

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

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

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

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

س: تركني "المزيف حتى تصنعه" مع الكثير من الكود الفوضوي الذي قضيته لاحقًا الكثير من الوقت لإعادة التنظيف والتنظيف. هل هذه هي الطريقة التي تعمل بها الأمور؟

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

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

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

أيضا ، لا تقيس منحنى التعلم. تألفت أول تجربة حقيقية TDD من إعادة كتابة 3 أشهر من العمل في 9 أيام ، 14 ساعة. كان لدي 125 اختبار استغرق 12 دقيقة للركض. لم يكن لدي أي فكرة عما كنت أفعله ، وشعرت بطيئًا ، لكنه بدا ثابتًا ، وكانت النتائج رائعة. لقد أعادت الكتابة بشكل أساسي في 3 أسابيع ما الذي استغرقه أصلاً 3 أشهر لأخطئ. إذا كتبت ذلك الآن ، فربما كان بإمكاني القيام بذلك في غضون 3-5 أيام. الفرق؟ سيكون لجناح الاختبار الخاص بي 500 اختبار يستغرق تشغيل 1-2 ثانية. جاء ذلك مع الممارسة.

Answer 4

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

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

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

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

الترميز صعب. لنذهب للتسوق.

Answer 5

لنقطة واحدة ، انظر أ سؤال سألت بعض الوقت فيما يتعلق بنقطة أولى.

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

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

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

أوصي مدونة اختبار Google بشدة لأن بعض المقالات الموجودة هناك جعلت الاختبار لمشاريع TDD أفضل بكثير.

Answer 6

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

بدأت أفعل TDD ربما قبل 6 أشهر؟ ما زلت أتعلم نفسي. أستطيع أن أقول مع مرور الوقت اختباراتي ورمزاتي أفضل بكثير ، لذلك استمر في ذلك. أنا حقا أوصي كتاب أنماط تصميم Xunit أيضًا.

Answer 7

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

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

• اختبار اتصال العميل الناجح
• اختبار خطأ اتصال العميل نوع 1
• اختبار خطأ اتصال العميل النوع 2
• اختبار اتصال العميل الناجح
• فشل اختبار اتصال العميل عندما لا يكون متصلاً

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

كيف تتعامل مع إعادة الكتابة؟

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

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