لماذا يجب علي استخدام التطوير المبني على الاختبار؟[ينسخ]

Question

ينسخ:

• لماذا يجب أن أمارس التطوير المبني على الاختبار وكيف يجب أن أبدأ؟

بالنسبة للمطور الذي لا يعرف شيئًا عن التطوير المبني على الاختبار، ما هي المشكلة (المشكلات) التي سيتم حلها من خلال اعتماد TDD؟

[تحرير] لنفترض أن المطور (ab) يستخدم بالفعل إطار عمل اختبار الوحدة.

Answer 1

فيما يلي ثلاثة أسباب قد تجعل TDD يساعد المطور/الفريق:

• فهم أفضل لما ستكتبه
• يفرض سياسة كتابة الاختبارات بشكل أفضل قليلاً
• يسرع التنمية

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

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

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

قد يكون من الصعب إقناع نفسك أو الآخرين بكتابة الاختبارات أولاً.قد يكون من الأفضل أن تجعلهم يكتبون كليهما في نفس الوقت وهو ما قد يكون مفيدًا بنفس القدر.

Answer 2

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

إذا لم يكن هذا صحيحًا، فلديك مشكلات أخرى عليك التعامل معها.

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

يبدو جيدا حتى الآن، نعم؟

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

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

Answer 3

(هذا تعليق يتفق مع إجابة duffymo أكثر من كونه إجابة خاصة به.)

إجابات دوفيمو:

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

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

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

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

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

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

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

كل ما أقوله هو أن الإصرار الوثني على "الاختبار أولاً" يربك طريقة (واحد من كثيرين) مع هدف, مما يجعل المبرمج يفكر فيما يقوم بترميزه.

* لكي أكون مسكونيًا، سأشير إلى أن كلا من الكاثوليك والمسلمين يستخدمون المسابح.ومرة أخرى، إنها أ ميكانيكي, ، طريقة الذاكرة العضلية لوضع النفس في إطار ذهني معين.إنه صنم (بالمعنى الأصلي للشيء السحري، وليس معنى "الصنم الجنسي") أو سحر الحظ السعيد.وكذلك قول "Om mani Padme hum"، أو الجلوس زازين، أو مداعبة قدم أرنب "محظوظ"، (ليس محظوظًا بالنسبة للأرنب). الفيلسوف جيري فودور، عند التفكير في المشكلات الصعبة، لديه طقوس مماثلة:يكرر لنفسه ، "هيا ، جيري ، يمكنك فعل ذلك!" (لقد جربت ذلك أيضا ، ولكن نظرا لأن اسمي ليس جيري ، فإنه لم ينجح معي.;)))

Answer 4

من الناحية المثالية:

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

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

Answer 5

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

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

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

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

Answer 6

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

1) تحدث مع العميل حول ما يفترض أن يفعله التطبيق، وكيف من المفترض أن يتفاعل مع المواقف المختلفة.

2) قم بترجمة نتيجة 1) إلى اختبارات الوحدة، والتي تختبر كل ميزة أو سيناريو واحد.

3) اكتب كودًا بسيطًا "غير دقيق" ينجح (بالكاد) في الاختبارات.عندما يتم ذلك، تكون قد حققت توقعات عميلك.

4) أعد صياغة الكود الذي كتبته 3) حتى تعتقد أنك قمت بذلك بأكثر الطرق فعالية.

عند الانتهاء من ذلك، نأمل أن تكون قد أنتجت تعليمات برمجية عالية الجودة تلبي احتياجات عميلك.إذا كان العميل يريد الآن ميزة جديدة، عليك أن تبدأ الدورة من جديد - ناقش الميزة، واكتب اختبارًا للتأكد من أنها تعمل، واكتب التعليمات البرمجية التي تجتاز الاختبار، وأعد البناء.

وكما قال الآخرون، في كل مرة تقوم فيها بإجراء اختباراتك، فإنك تتأكد من أن الكود القديم لا يزال يعمل، وأنه يمكنك إضافة وظائف جديدة دون كسر الكود القديم.

Answer 7

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

Answer 8

لقد بذلت جهدًا كبيرًا لتعلم TDD لتطوير Ruby on Rails.لقد استغرق الأمر عدة أيام قبل أن أتمكن من ذلك حقًا.لقد كنت متشككًا جدًا ولكني بذلت هذا الجهد لأن المبرمجين الذين أحترمهم يدعمون ذلك.

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

Answer 9

يوفر TDD (التطوير/ التصميم القائم على الاختبار) المزايا التالية

• يضمن لك معرفة معايير قبول بطاقة القصة قبل البدء
• يضمن أنك تعرف متى تتوقف عن البرمجة (أي عندما يتم استيفاء معايير القبول وبالتالي يمنع الطلاء بالذهب)

ونتيجة لذلك، ينتهي بك الأمر برمز

1. قابل للاختبار
2. تصميم نظيف
3. قادرة على إعادة هيكلتها بثقة
4. الحد الأدنى من التعليمات البرمجية اللازمة لتلبية بطاقة القصة
5. مواصفات حية لكيفية عمل الكود
6. قادرة على دعم وتيرة مستدامة من الميزات الجديدة

Answer 10

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

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

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

Answer 11

هناك العديد من المزايا:

• جودة كود أعلى
• أخطاء أقل
• وقت ضائع أقل

أي من هذه العناصر وحدها ستكون مبررًا كافيًا لتنفيذ TDD.