مساوئ التطوير القائم على الاختبار؟[مغلق]

https://stackoverflow.com/questions/64333

09-06-2019
|

سؤال

ما الذي أخسره من خلال اعتماد التصميم القائم على الاختبار؟

قائمة السلبيات فقط؛لا تدرج الفوائد المكتوبة بصيغة سلبية.

المحلول

العديد من الجوانب السلبية (وأنا لا أدعي عدم وجود فوائد - خاصة عند كتابة أساس المشروع - سيوفر الكثير من الوقت في النهاية):

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

نصائح أخرى

إذا كنت تريد القيام بـ TDD "حقيقي" (اقرأ:اختبر أولاً باستخدام خطوات إعادة التصنيع باللون الأحمر والأخضر) ثم يتعين عليك أيضًا البدء في استخدام نماذج/بذرة، عندما تريد اختبار نقاط التكامل.

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

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

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

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

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

كل هذه الاختبارات تجعل من الصعب جدًا "تغيير" (على عكس إعادة البناء) سلوك نظامك وتصبح التغييرات البسيطة صعبة للغاية وتستغرق وقتًا طويلاً.

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

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

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

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

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

يستغرق الأمر وقتًا طويلاً لإدخال عقلك في "وضع الاختبار" وكتابة "رمز قابل للاختبار" هي مهارة في حد ذاتها.

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

لذا (المنظمة البحرية الدولية) باختصار:

مقدار الوقت المستغرق في التفكير (أي:في الواقع grok'ing اختبارات).
المعرفة الجديدة المطلوبة لمعرفة كيفية كتابة تعليمات برمجية قابلة للاختبار.
فهم التغييرات المعمارية المطلوبة لجعل التعليمات البرمجية قابلة للاختبار.
زيادة مهاراتك في "TDD-Coder" أثناء محاولتك تحسين جميع المهارات الأخرى المطلوبة لحرفتنا البرمجية الرائعة :)
قم بتنظيم قاعدة التعليمات البرمجية الخاصة بك لتشمل رمز الاختبار دون إفساد رمز الإنتاج الخاص بك.

ملاحظة:إذا كنت ترغب في روابط للإيجابيات، فقد قمت بطرح عدة أسئلة وأجبت عليها، راجع موقعي حساب تعريفي.

في السنوات القليلة التي كنت أمارس فيها التطوير المبني على الاختبار، يجب أن أقول إن أكبر السلبيات هي:

بيعها للإدارة

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

بيعه لمطورين آخرين

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

الحفاظ على رمز الاختبار مع رمز الإنتاج الخاص بك

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

كتابة الاختبارات بحيث تغطي كل شيء (تغطية الكود بنسبة 100%)

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

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

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

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

في مشروع TDD الأول الخاص بك، هناك خسارتان كبيرتان، الوقت والحرية الشخصية

تخسر الوقت بسبب:

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

تفقد حريتك الشخصية بسبب:

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

أتمنى أن يساعدك هذا

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

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

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

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

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

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

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

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

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

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

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

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

لقد واجهت العديد من المواقف التي جعلني فيها TDD مجنونًا.لتسمية بعض:

قابلية صيانة حالة الاختبار:

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

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

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

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

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

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

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

تفقد القدرة على كتابة مئات أو آلاف الأسطر من التعليمات البرمجية قبل تشغيلها.

تفقد فرصة التعلم من خلال التصحيح.

ستفقد المرونة في إرسال رمز لم تكن متأكدًا منه.

تفقد الحرية في ربط الوحدات النمطية الخاصة بك بإحكام.

ستفقد خيار تخطي كتابة وثائق التصميم ذات المستوى المنخفض.

ستفقد الاستقرار الذي يأتي مع الكود الذي يخشى الجميع تغييره.

تفقد لقب "الهاكر".

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

إذا كنت تعمل في شركة تدفع لك من خلال KLOCs (أو المتطلبات المطبقة - حتى لو لم يتم اختبارها) فابتعد عن TDD (أو مراجعات التعليمات البرمجية، أو البرمجة الزوجية، أو التكامل المستمر، وما إلى ذلك).إلخ.إلخ.).

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

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

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

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

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

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

سوف تفقد فصولًا كبيرة ذات مسؤوليات متعددة.من المحتمل أيضًا أن تفقد أساليب كبيرة ذات مسؤوليات متعددة.قد تفقد بعض القدرة على إعادة البناء، لكنك ستفقد أيضًا بعض الحاجة إلى إعادة البناء.

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

أقول إن هذا يشير إلى تجريد مفقود - إذا كان الكود الخاص يحتاج حقًا إلى الاختبار، فمن المحتمل أن يكون في فئة منفصلة.

ديف مان

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

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

TDD هي مهارة لذا قد يواجه المطورون المبتدئون صعوبة في البداية (لأنهم لم يتعلموا العمل بهذه الطريقة بشكل رئيسي).

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

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

يتطلب اختبار الوحدة المزيد من التعليمات البرمجية للكتابة، وبالتالي تكلفة تطوير أولية أعلى
إنه المزيد من التعليمات البرمجية للحفاظ عليها
التعلم الإضافي المطلوب

إجابات جيدة للجميع.أود أن أضيف بعض الطرق لتجنب الجانب المظلم من TDD:

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

يتطلب TDD تنظيمًا معينًا للتعليمات البرمجية الخاصة بك.قد يكون هذا غير فعال أو يصعب قراءته.أو حتى خطأ معماريا؛على سبيل المثال، منذ private لا يمكن استدعاء الأساليب خارج الفصل الدراسي، عليك أن تجعل الأساليب غير خاصة لجعلها قابلة للاختبار، وهذا خطأ تمامًا.

عندما يتغير الكود، يجب عليك تغيير الاختبارات أيضًا.مع إعادة إنشاء هذا يمكن أن يكون الكثير من العمل الإضافي.

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

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

عليك التأكد من أن اختباراتك محدثة دائمًا، فاللحظة التي تبدأ فيها بتجاهل الأضواء الحمراء هي اللحظة التي تصبح فيها الاختبارات بلا معنى.

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

الشخص الذي علم فريقي التطوير السريع لم يكن يؤمن بالتخطيط، لقد كتبت الكثير فقط من أجل أصغر المتطلبات.

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

يزيد وقت التطوير:تحتاج كل طريقة إلى الاختبار، وإذا كان لديك تطبيق كبير به تبعيات، فأنت بحاجة إلى إعداد بياناتك وتنظيفها للاختبارات.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow