ما هو التطوير القائم على الاختبار (TDD)؟ مثال

ما هو التطوير القائم على الاختبار (TDD)؟

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

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

التطوير المبني على الاختبار (TDD): تعلم باستخدام المثال

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

التطوير المبني على الاختبار هو عملية تطوير وتشغيل اختبار آلي قبل التطوير الفعلي للتطبيق. ومن ثم، يُطلق على TDD أحيانًا أيضًا اسم اختبار التطوير الأول.

كيفية إجراء اختبار TDD

فولوwing تحدد الخطوات كيفية إجراء اختبار TDD،

  1. أضف اختبارًا.
  2. قم بإجراء كافة الاختبارات ومعرفة ما إذا كان أي اختبار جديد قد فشل.
  3. اكتب بعض التعليمات البرمجية.
  4. قم بإجراء الاختبارات وكود Refactor.
  5. كرر.

خمس خطوات للتطوير القائم على الاختبار

خمس خطوات للتطوير القائم على الاختبار

تحدد دورة TDD

  1. اكتب اختبارًا
  2. اجعله يعمل.
  3. قم بتغيير الكود لتصحيحه، أي Refactor.
  4. كرر العملية.

بعض التوضيحات حول TDD:

  • نهج TDD لا يتعلق بـ "الاختبار" ولا يتعلق بـ "التصميم".
  • TDD لا يعني “اكتب بعض الاختبارات، ثم قم ببناء نظام يجتاز الاختبارات.
  • TDD لا يعني "إجراء الكثير من الاختبارات".

مقابل TDD. الاختبار التقليدي

فيما يلي الفرق الرئيسي بين التطوير القائم على الاختبار والاختبار التقليدي:

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

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

ما هو قبول TDD والمطور TDD

هناك مستويان من TDD

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

التطوير المبني على الاختبار (TDD): تعلم باستخدام المثال

توسيع نطاق TDD عبر التطوير المدفوع بالنموذج الرشيق (AMDD)

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

وبالتالي يتم استخدام AMDD لقضايا أكبر.

دورة حياة AMDD

التطوير المبني على الاختبار (TDD): تعلم باستخدام المثال

في التطوير المبني على النماذج (MDD)، يتم إنشاء نماذج شاملة قبل كتابة الكود المصدري. والتي بدورها لديها نهج رشيق؟

في الشكل أعلاه، كل منهما box يمثل نشاطًا تنمويًا.

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

إنها العملية التي لا يتم فيها وضع مواصفات تفصيلية للبرنامج/النظام ولكن استكشاف متطلبات البرنامج/النظام الذي يحدد الاستراتيجية العامة للمشروع.

التكرار 0: التصور

هناك نوعان من التنشيطات الفرعية الرئيسية.

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

نمذجة التكرار

هنا يجب على الفريق تخطيط العمل الذي سيتم القيام به لكل تكرار.

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

اقتحام نموذجي

يُعرف هذا أيضًا باسم النمذجة في الوقت المناسب.

  • تتضمن جلسة النمذجة هنا فريقًا مكونًا من 2/3 أعضاء يناقشون المشكلات على الورق أو السبورة البيضاء.
  • سيطلب أحد أعضاء الفريق من عضو آخر أن يصمم نموذجًا معه. ستستغرق جلسة النمذجة هذه حوالي 5 إلى 10 دقائق. حيث يجتمع أعضاء الفريق معًا لمشاركة السبورة/الورق.
  • يستكشفون المشكلات حتى لا يجدوا السبب الرئيسي للمشكلة. في الوقت المناسب، إذا حدد أحد أعضاء الفريق المشكلة التي يريد حلها، فسوف يتلقى مساعدة سريعة من أعضاء الفريق الآخرين.
  • يقوم بعد ذلك أعضاء المجموعة الآخرون باستكشاف المشكلة ثم يستمر الجميع كما كان من قبل. ويُطلق عليها أيضًا اسم النمذجة الاحتياطية أو جلسات ضمان الجودة للعملاء.

التطوير القائم على الاختبار (TDD)

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

الاستعراضات

  • هذا اختياري. ويشمل عمليات فحص الكود ومراجعات النماذج.
  • يمكن القيام بذلك لكل تكرار أو للمشروع بأكمله.
  • يعد هذا خيارًا جيدًا لتقديم تعليقات حول المشروع.

التطوير القائم على الاختبار (TDD) مقابل التطوير القائم على الاختبار (TDD) التطوير المدفوع بالنموذج الرشيق (AMDD)

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

أطر TDD

فيما يلي قائمة بأفضل أطر التطوير المستندة إلى الاختبار (TDD).

  1. جونيت
  2. اختبار
  3. csUnit وNUnit
  4. Rspec

الآن، دعونا نتعلم التطوير المبني على الاختبار بالقدوة.

مثال على TDD

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

شرط قبول كلمة المرور:

  • يجب أن تتكون كلمة المرور من 5 إلى 10 حرفًا.

أولاً في مثال TDD هذا، نكتب الكود الذي يلبي جميع المتطلبات المذكورة أعلاه.

التطوير المبني على الاختبار (TDD): تعلم باستخدام المثال

السيناريو شنومكس: لإجراء الاختبار، نقوم بإنشاء فئة كلمة المرورValidator ()؛

التطوير المبني على الاختبار (TDD): تعلم باستخدام المثال

سنقوم بتشغيل فئة TestPassword () فوقها؛

يتم تمرير الإخراج كما هو موضح أدناه؛

الناتج:

التطوير المبني على الاختبار (TDD): تعلم باستخدام المثال

السيناريو شنومكس: هنا يمكننا أن نرى في طريقة TestPasswordLength () ليست هناك حاجة لإنشاء مثيل لفئة PasswordValidator. المثيل يعني إنشاء موضوع للفئة لإحالة أعضاء (المتغيرات/الطرق) لتلك الفئة.

التطوير المبني على الاختبار (TDD): تعلم باستخدام المثال

سنقوم بإزالة فئة كلمة المرورValidator pv = كلمة المرور الجديدة () من الكود. يمكننا الاتصال ب صالح () الطريقة مباشرة عن طريق كلمة المرورValidator. صالح ("Abc123"). (انظر الصورة أدناه)

لذلك قمنا بإعادة البناء (تغيير الكود) على النحو التالي:

التطوير المبني على الاختبار (TDD): تعلم باستخدام المثال

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

التطوير المبني على الاختبار (TDD): تعلم باستخدام المثال

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

التطوير المبني على الاختبار (TDD): تعلم باستخدام المثال

الإخراج:

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

التطوير المبني على الاختبار (TDD): تعلم باستخدام المثال

مزايا TDD

فولوwing هي المزايا الرئيسية للتطوير القائم على الاختبار في هندسة البرمجيات:

الإخطار المبكر بالأخطاء.

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

كود أفضل تصميمًا وأكثر نظافة وقابلية للتوسعة.

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

الثقة في إعادة البناء

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

جيد للعمل الجماعي

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

جيد للمطورين

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

ملخص:

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