TDD مقابل BDD: ما الفرق بينهما؟ – سبوتو

يواصل الناس النقاش والكتابة عن TDD مقابل BDD والاختلافات بينهما في تطوير البرمجيات. على الرغم من وجود الكثير من منشورات المدونات التي تحاول حسم النقاش بشكل نهائي، إلا أنها لم تحقق نجاحًا يذكر.
لهذا السبب، قمنا بتجميع منشور مدونة حول TDD مقابل BDD لشرح ذلك بشكل شامل. سنصل إلى الإجابة في سلسلة من الخطوات. ومع ذلك، لسنا متأكدين من كيفية معالجة هذه المقالة، لذا ابق معنا حتى النهاية.
ما هو التطوير القائم على الاختبار- TDD؟
التطوير المدفوع بالاختبار (TDD) هو ممارسة شائعة لتطوير كود برمجي بسيط وقابل للصيانة ومختبر بشكل جيد. ينص النهج على أنه يجب على المرء كتابة “كود التنفيذ” فقط في حالة وجود “حالة اختبار فاشلة”. إنه نهج تكراري لتطوير المنتجات البرمجية حيث –
تتم كتابة حالة اختبار فاشلة,
يتم إنشاء رمز عمل كافٍ، مما يجعل حالة الاختبار الفاشلة تنجح
ثم إذا لزم الأمر، يتم إعادة هيكلة الكود بأكمله.
وأخيراً، يتم تكرار العملية بأكملها، وإنشاء المزيد من الاختبارات على مدى فترة من الزمن.
ما هي عملية التطوير القائم على الاختبار -TDD؟
1قبل العمل على التعليمات البرمجية، من الضروري التأكد من أن عميلك يفهم ما تقوم ببنائه أو إنشائه. في النهاية، إذا كنت لا تعرف كيف يخطط عملاؤك لاستخدام البرنامج، فمن المحتمل جدًا ألا يستخدمه أحد بالفعل بمجرد بنائه. يعد اختيار طريقة لهم للإبلاغ عما إذا كانت الميزات تعمل أم لا جانبًا مهمًا في هذه الخطوة. قد يصبح فهم الأمور أسهل بكثير بمساعدة قصص وسيناريوهات المستخدم، والتي يمكن كتابتها بطرق مختلفة مثل “عندما … ثم يجب أن نرى … بحيث يقوم المستخدمون …”
2اكتب اختبار الوحدة لحالة الاستخدام الخاصة بك. افعل ذلك قبل كتابة أي تنفيذ للتعليمات البرمجية لحالة الاستخدام. بعد الانتهاء من كل ذلك واكتماله، قم بتشغيل اختباراتك للتأكد من فشلها أو إصلاح أي خلل فيها. نعم، في البداية، من المحتمل أن تفشل في البداية لأنك لم تقم بعد بتنفيذ جميع التعليمات البرمجية اللازمة لإكمالها بنجاح.
3الفكرة من وراء كتابة اختبار الوحدة هي أن نعرف بثقة أن ما كتبناه أثناء الاختبار يعمل على النحو المنشود. إذا كان هناك شيء ما موجود بالفعل في برنامجنا بشكل أو بشكل ما. في هذه الحالة، قد نكون نكرر شيئًا ما وبالتالي نضيع الوقت في فتح نافذة ثانية فقط للقيام بشيء صغير جدًا في حين قد لا تكون هناك حاجة لنافذة أخرى أصلاً.
من الأفضل أن نتعرف على كيفية عمل كل شيء معًا بدلًا من إنشاء المزيد من الأشياء لمجرد أننا نريد التنويع أو لمجرد أن أحدهم قد يعتقد أن الأمر سيكون أكثر متعة بهذه الطريقة.
4لتقليل كمية التعليمات البرمجية التي عليك كتابتها، اكتب الحد الأدنى الذي يجعل اختباراتك تنجح. بمجرد أن تتمكن من تشغيل هذا الاختبار باستمرار وعدم العثور على أي أخطاء، تكون مستعدًا للانتقال إلى كتابة حالات الاختبار لحالة الاستخدام التالية.
5اكتب حالة اختبار تغطي كل وظيفة جديدة مكتوبة بنفس طريقة كتابة حالة الاختبار الأولى. للقيام بذلك، نحتاج إلى أن نكون قادرين على تعديل اختباراتنا المؤتمتة عند إجراء تغييرات على شيفرتنا المصدرية.
ارتقِ بحياتك المهنية من خلال دورتنا التدريبية لشهادة CSD المعتمدة.
أطلق العنان لإمكانياتك كمطوِّر معتمد من خلال دورتنا التدريبية الشاملة لشهادة CSD. اكتسب خبرة عملية ومهارات قيّمة للتفوق في تطوير البرمجيات الرشيقة.
1ينقسم التصميم إلى مراحل: عند استخدام نهج TDD، يركز المطورون على مجموعة صغيرة من التعليمات البرمجية في كل مرة، ولا ينتقلون إلى الجزء التالي حتى ينتهوا من مجموعتهم.
إذا تمت كتابتها بهذه الطريقة، يتم تحسين جودة التعليمات البرمجية بشكل طبيعي، مما يسهل اكتشاف الأخطاء دون الكثير من العناء وإعادة استخدام أجزاء صغيرة من التعليمات البرمجية لإنشاء ميزات جديدة. وهذا يحسن في نهاية المطاف بنية الحل.
وهذا يتوافق مع مبادئ تصميم البرمجيات المعيارية ويعلم المطورين أيضًا الحفاظ على نظافة الشيفرة البرمجية.
2سهولة صيانة الكود البرمجي: يكون العمل حسب الضرورة مع التعليمات البرمجية المرتبة بترتيب محدد أسهل بكثير عند الحاجة إلى إجراء تغييرات وتعديلات.
عندما يعمل المطورون وفقًا لنهج التطوير المدفوع بالاختبار، فإنهم بطبيعة الحال ينتجون كودًا أنظف وأكثر قابلية للقراءة وأكثر قابلية للإدارة.
إن التركيز على أجزاء كود أصغر وأكثر قابلية للهضم يسهل على المطورين الالتزام بمتطلبات الاختبار ويضع ضغطًا أقل عليهم، وبالتالي يسهل عليهم التعامل مع المهام الأخرى التي يقومون بها.
تكون التعليمات البرمجية الأصلية النظيفة مفيدة بشكل خاص عندما يتم نقل المهمة أو المشروع إلى أعضاء مختلفين من فريق المنتج.
3إعادة التصحيح باستمرار: من الجيد دائمًا مراجعة عملك في نهاية كل يوم. تتمثل إحدى الاستراتيجيات في تشغيل جميع الاختبارات، ومعرفة أين تفشل، والتعامل معها واحدًا تلو الآخر. عندما تقوم بإصلاح جانب واحد من البرنامج يمكن أن يؤثر ذلك بشكل غير مباشر على الأجزاء الأخرى التي كانت تعمل بشكل جيد في السابق.
في بعض الأحيان يكون هناك تضارب في هذه التغييرات، وقد يكون من الضروري إجراء تعديلات مستمرة بين الاختبارات المختلفة، ولهذا السبب فإن التأكد من أن لديك بيئة اختبار قوية أمر مهم للغاية.
إن الهدف الرئيسي من إعادة هيكلة الشيفرة البرمجية هو تحسين قدرتها على إخبارك -المؤلف- بما تفعله. من خلال الحصول على تغذية راجعة من الشيفرة، يمكننا التأكد من أنها تعمل كما هو متوقع طوال الوقت وفي كل مرة.
4انخفاض تكاليف المشروع وزيادة العائد على الاستثمار: مع وجود التطوير المدفوع بالاختبار في صميم سير عملك، يمكنك إنشاء برامج أرخص ثمناً بشكل أسرع. أخطاء أقل تعني قضاء وقت أقل في تصحيح الأخطاء وبناء ميزات جديدة!
الأكثر طلباً
أتقن المهارات الأساسية من خلال إرشاداتنا وانطلق إلى مستقبل التكنولوجيا كمهندس تطوير قائم على السلوك.
أهم الفوائد الرئيسية للتطوير القائم على السلوك -BDD
1إضافة: يعد التطوير المدفوع بالسلوك (BDD) طريقة رائعة للعمل مع فرق المنتج لضمان تضمين مجموعة المتطلبات الصحيحة في البرنامج الذي يتم تطويره.
يستعير BDD بشكل كبير من منهجية الأصدقاء الثلاثة ولكنه يضمن التعاون بين العملاء ومحللي الأعمال والمطورين أثناء المضي قدمًا في تطوير المنتج لأنه متضمن جيدًا في منهجيات التطوير الرشيقة مثل Scrum أو Kanban.
في جوهرها، يعدّ منهجية BDD تحسينًا لمنهجية “الأصدقاء الثلاثة” حيث يتم استخدام معايير القبول مثل اختبارات التكامل أثناء تطوير واختبار الميزات من قبل فريق متعدد الوظائف.
2الشفافية: عند وصف سلوك منتجك، تكون السيناريوهات موجزة وسهلة الفهم. يصف كل سيناريو جانبًا فريدًا من التجربة.
وهذا يسهل على العميل فهم الفكرة بأكملها بمصطلحات الشخص العادي، بحيث يمكنه وصف ما يريده بدقة عندما يريده.
3منظمة بشكل جيد: تم تصميم BDD لتسريع عملية التطوير. يعتمد جميع المشاركين في التطوير على نفس السيناريوهات. السيناريوهات هي المتطلبات، ومعايير القبول، وحالات الاختبار، والنصوص البرمجية للاختبار في آنٍ واحد – ليست هناك حاجة لكتابة أي قطعة أثرية أخرى.
تعمل الطبيعة المعيارية لصيغة Gherkin على تسريع تطوير أتمتة الاختبار. وعلاوة على ذلك، يمكن استخدام السيناريوهات كخطوات لإعادة إنتاج حالات الفشل لتقارير العيوب.
4التحول لليسار: التحول لليسار هو أسلوب يجلب الاختبار في وقت مبكر من العملية. اختبار مبكر لاكتشاف الأخطاء في وقت مبكر. تتناسب تقنية BDD مع التحول لليسار بشكل جيد مع التحول لليسار لأن TDD و ATDD تصبح جزءًا من تعريف المتطلبات لمشاريع الشلال التقليدية أو التهيئة لمشاريع Agile. بمجرد كتابة سيناريوهات السلوك، يحين الوقت لبدء الاختبار والأتمتة.
5السيناريوهات: السيناريوهات، التي تشكل التكوين النهائي لمشروع الاختبار، هي أشبه بمجموعة من المقالات التوثيقية الذاتية التي توثق كل اختبار من الاختبارات المختلفة التي تم إجراؤها.
تعد هذه المجموعة المتزايدة باستمرار مثالية لاختبار الانحدار لأنها تسمح لأي شخص يقوم بتقييم نجاح أو فشل منتج معين بقراءة مجموعة من التعليمات سهلة المتابعة وجيدة التنظيم حول كيفية إنجاز أي مهمة وتحديد ما إذا كان المنتج المعطى قد أنجز كل خطوة بنجاح أم لا.
الفرق بين TDD و BDD
عند الطلب
أتقن المهارات الأساسية من خلال إرشاداتنا وانطلق إلى مستقبل التكنولوجيا كمهندس تطوير في مرحلة التطوير أولاً.
التطوير القائم على الاختبار أولاً هو منهجية تعمل بشكل جيد للغاية عند إقرانها مع التطوير المدفوع بالسلوك. يخلق هذا الاقتران تركيزًا أكبر على الاختبار من منظور المطور، ويقوم بذلك بطريقة فعالة من خلال إنشاء أنواع مختلفة من اختبارات الوحدة للمكونات القوية (التي) تضمن عمل كل مكون كما هو متوقع بمفرده (وعند دمجهما لتشكيل التطبيقات).
الخلاصة
يخدم كل من TDD و BDD أغراضهما. يجب على الفرق الرشيقة أن تقرر ما يناسبها وتستخدم كلاهما بشكل متناسب لجني فوائدهما. اقرأ تعريف وعملية وفوائد TDD و BDD والتي يمكن أن تساعدك على فهم استخدامات كليهما.
الأسئلة المتداولة
الأسئلة المتداولة
نعم، تستخدم العديد من الفرق كلا المنهجيتين معًا. يمكن أن توجه منهجية BDD التصميم العام والمتطلبات، بينما يمكن أن تضمن منهجية TDD عمل الوحدات الفردية على النحو المنشود.
تشمل أدوات BDD الشائعة Cucumber وSpecFlow وJBehave، والتي تسمح للمطورين بكتابة الاختبارات بلغة بسيطة.
تشمل أدوات TDD الشائعة JUnit لجافا و NUnit لـ .NET و Mocha لجافا سكريبت، مع التركيز على كتابة اختبارات الوحدة.
استخدم BDD عندما تريد توضيح المتطلبات وإشراك أصحاب المصلحة في تحديد سلوك التطبيق. استخدم TDD عند التركيز على جودة التعليمات البرمجية واختبار الوحدة.
اشترك في النشرة الإخبارية لسبوتو
ابق على اطلاع بأحدث اتجاهات Agile & Scrum.