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

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

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

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

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

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

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

الخطوات التالية تحدد كيفية إجراء اختبار 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 عبر التطوير المدفوع بالنموذج الرشيق (AMDD)

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

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

دورة حياة AMDD

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

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

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

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

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

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

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

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

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

• يتم استخدام عملية 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. TestNG
3. csUnit وNUnit
4. Rspec

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

مثال على TDD

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

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

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

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

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

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

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

الناتج:

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

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

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

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

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

الإخراج:

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

مزايا TDD

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

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

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

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

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

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

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

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

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

جيد للمطورين

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

الملخص

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