ما هي الاختلافات الأساسية بين TDD و BDD؟
https://stackoverflow.com/questions/2509
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لقد كان التطوير القائم على الاختبار هو الغضب السائد في مجتمع .NET خلال السنوات القليلة الماضية.لقد سمعت مؤخرًا تذمرًا في مجتمع ALT.NET حول BDD.ما هذا؟ما الذي يجعلها مختلفة عن TDD؟
المحلول
أنا أفهم أن BDD يجب أن يكون أكثر تخصيص من اختبارات.إنه مرتبط بالتصميم المستند إلى المجال (ألا تحب اختصارات *DD هذه؟).
ويرتبط بطريقة معينة لكتابة قصص المستخدمين، بما في ذلك الاختبارات عالية المستوى.مثال بواسطة توم تن ثيج:
Story: User logging in
As a user
I want to login with my details
So that I can get access to the site
Scenario: User uses wrong password
Given a username 'jdoe'
And a password 'letmein'
When the user logs in with username and password
Then the login form should be shown again
(في مقالته، يواصل توم تنفيذ مواصفات الاختبار هذه مباشرة في روبي.)
بابا BDD هو دان نورث.ستجد مقدمة رائعة في كتابه تقديم بي دي دي شرط.
ستجد مقارنة بين BDD وTDD في هذا فيديو.أيضًا رأي حول BDD باسم "TDD تم تنفيذه بشكل صحيح" بواسطة جيريمي د.ميلر
تحديث 25 مارس 2013
الفيديو أعلاه مفقود منذ فترة.إليكم واحدة حديثة من لويلين فالكو، BDD مقابل TDD (موضح).أجد تفسيره واضحا وفي صلب الموضوع.
نصائح أخرى
بالنسبة لي، الفرق الأساسي بين BDD وTDD هو التركيز والصياغة.والكلمات مهمة لتوصيل نيتك.
يوجه TDD التركيز على الاختبار.وبما أن الاختبارات في "عالم الشلال القديم" تأتي بعد التنفيذ، فإن هذه العقلية تؤدي إلى فهم وسلوك خاطئين.
يوجه التشوه الذهني (BDD) التركيز على السلوك والمواصفات، وبالتالي يتم تشتيت العقول الشلالية.لذلك يمكن فهم BDD بسهولة أكبر على أنه ممارسة تصميمية وليس ممارسة اختبار.
يبدو أن هناك نوعين من BDD.
الأول هو النمط الأصلي الذي ناقشه دان نورث والذي تسبب في إنشاء أطر عمل أسلوب xBehave.بالنسبة لي، ينطبق هذا النمط بشكل أساسي على اختبار القبول أو المواصفات مقابل كائنات المجال.
النمط الثاني هو ما قام Dave Astels بترويجه والذي، بالنسبة لي، هو شكل جديد من TDD له بعض الفوائد الجسيمة.إنه يركز على السلوك بدلاً من الاختبار وأيضًا فئات الاختبار الصغيرة، محاولًا الوصول إلى النقطة التي يكون لديك فيها سطرًا واحدًا لكل طريقة (اختبار) للمواصفات.يناسب هذا النمط جميع مستويات الاختبار ويمكن إجراؤه باستخدام أي إطار عمل اختبار وحدة موجود على الرغم من أن الأطر الأحدث (نمط xSpec) تساعد في التركيز على السلوك بدلاً من الاختبار.
هناك أيضًا مجموعة BDD التي قد تجدها مفيدة:
التطوير القائم على الاختبار هي منهجية تطوير برمجيات تعتمد على الاختبار الأول، مما يعني أنها تتطلب كتابة كود الاختبار قبل كتابة الكود الفعلي الذي سيتم اختباره.على حد تعبير كينت بيك:
النمط هنا هو كتابة بضعة أسطر من التعليمات البرمجية ، ثم الاختبار الذي يجب أن يتم تشغيله ، أو حتى أفضل ، لكتابة اختبار لن يتم تشغيله ، ثم كتابة الكود الذي سيجعله يعمل.
بعد معرفة كيفية كتابة جزء واحد من التعليمات البرمجية ، الآن ، بدلاً من الترميز فقط ، نريد الحصول على تعليقات فورية وممارسة "رمز قليلاً ، اختبر القليل ، رمز قليلاً ، اختبر قليلاً." لذلك نكتب على الفور اختبار لذلك.
لذا فإن TDD هي منهجية تقنية منخفضة المستوى يستخدمها المبرمجون لإنتاج كود نظيف يعمل.
التنمية المدفوعة بالسلوك هي منهجية تم إنشاؤها بناءً على TDD، ولكنها تطورت إلى عملية لا تتعلق فقط بالمبرمجين والمختبرين، ولكنها تتعامل بدلاً من ذلك مع الفريق بأكمله وجميع أصحاب المصلحة المهمين، التقنيين وغير التقنيين.بدأ BDD ببعض الأسئلة البسيطة التي لم يجيب عليها TDD بشكل جيد:كم عدد الاختبارات التي يجب أن أكتبها؟ما الذي يجب أن أختبره بالفعل، وما الذي لا ينبغي عليّ اختباره؟أي من الاختبارات التي أكتبها سيكون في الواقع مهمًا للشركة أو للجودة الشاملة للمنتج، وما هي تلك الاختبارات التي تمثل مجرد هندسة مفرطة؟
كما ترون، تتطلب مثل هذه الأسئلة التعاون بين التكنولوجيا والأعمال.يمكن لأصحاب المصلحة في الأعمال وخبراء المجال في كثير من الأحيان إخبار المهندسين بنوع الاختبارات التي قد تكون مفيدة، ولكن فقط إذا كانت الاختبارات عبارة عن اختبارات عالية المستوى تتعامل مع جوانب الأعمال المهمة.يطلق BDD على مثل هذه الاختبارات الشبيهة بالأعمال اسم "أمثلة"، كما هو الحال في "أخبرني بمثال عن كيفية عمل هذه الميزة بشكل صحيح"، ويحتفظ بكلمة "اختبار" لعمليات التحقق الفنية ذات المستوى المنخفض مثل التحقق من صحة البيانات أو اختبار تكامل واجهة برمجة التطبيقات.الجزء المهم هو أنه في حين الاختبارات لا يمكن إنشاؤها إلا من قبل المبرمجين والمختبرين، أمثلة يمكن جمعها وتحليلها من قبل فريق التسليم بأكمله، من قبل المصممين والمحللين وما إلى ذلك.
باختصار، أحد أفضل تعريفات BDD التي لدي وجد حتى الآن هو أن BDD يدور حول "إجراء محادثات مع خبراء المجال واستخدام أمثلة لاكتساب فهم مشترك للسلوك المطلوب واكتشاف المجهول". جزء الاكتشاف مهم للغاية.عندما يجمع فريق التسليم المزيد من الأمثلة، يبدأون في فهم مجال الأعمال أكثر فأكثر، وبالتالي يقللون من عدم اليقين بشأن بعض جوانب المنتج الذي يتعين عليهم التعامل معه.ومع انخفاض حالة عدم اليقين، يزداد الإبداع والاستقلالية لدى فريق التسليم.على سبيل المثال، يمكنهم الآن البدء في اقتراح أمثلة خاصة بهم لم يعتقد مستخدمو الأعمال أنها ممكنة بسبب افتقارهم إلى الخبرة التقنية.
الآن، يبدو إجراء محادثات مع خبراء الأعمال والمجال أمرًا رائعًا، ولكننا جميعًا نعرف كيف ينتهي ذلك في كثير من الأحيان إلى الممارسة العملية.بدأت رحلتي مع التكنولوجيا كمبرمج.كمبرمجين، تعلمنا أن اكتب الكود- الخوارزميات، أنماط التصميم، التجريدات.أو، إذا كنت مصممًا، فسيتم تعليمك ذلك تصميم- تنظيم المعلومات وإنشاء واجهات جميلة.ولكن عندما نحصل على وظائف المبتدئين لدينا ، يتوقع أصحاب عملنا منا "تقديم قيمة للعملاء". ومن بين هؤلاء العملاء ، على سبيل المثال ...بنك.لكنني لم أكن أعرف شيئًا تقريبًا عن الخدمات المصرفية، باستثناء كيفية تقليل رصيد حسابي بكفاءة.لذلك يجب علي أن أترجم بطريقة أو بأخرى ما هو متوقع مني إلى كود ...يجب أن أقوم ببناء جسر بين الخدمات المصرفية وخبرتي الفنية إذا كنت أرغب في تقديم أي قيمة.يساعدني BDD في بناء مثل هذا الجسر على أساس ثابت من التواصل السلس بين فريق التسليم وخبراء المجال.
يتعلم أكثر
إذا كنت تريد قراءة المزيد عن اضطراب التشوه الجسمي، فقد كتبت كتابًا عن هذا الموضوع. "كتابة مواصفات رائعة" يستكشف فن تحليل المتطلبات وسيساعدك على تعلم كيفية بناء عملية BDD رائعة واستخدام الأمثلة كجزء أساسي من تلك العملية.يتحدث الكتاب عن اللغة واسعة الانتشار، وجمع الأمثلة، وإنشاء ما يسمى بالمواصفات القابلة للتنفيذ (الاختبارات الآلية) من الأمثلة - التقنيات التي تساعد فرق BDD على تقديم برامج رائعة في الوقت المحدد وفي حدود الميزانية.
إذا كنت مهتمًا بشراء "كتابة المواصفات الرائعة"، يمكنك توفير 39% مع الرمز الترويجي 39nicieja2 :)
لقد جربت قليلًا مع نهج BDD واستنتاجي السابق لأوانه هو أن BDD مناسب تمامًا لاستخدام تنفيذ الحالة، ولكن ليس على التفاصيل الأساسية.لا يزال TDD يتأرجح على هذا المستوى.
يستخدم BDD أيضًا كأداة اتصال.الهدف هو كتابة المواصفات القابلة للتنفيذ والتي يمكن أن يفهمها خبراء المجال.
يبدو لي أن BDD هو نطاق أوسع.وهذا يعني تقريبًا استخدام TDD، وأن BDD هي المنهجية الشاملة التي تجمع المعلومات والمتطلبات لاستخدام، من بين أمور أخرى، ممارسات TDD لضمان ردود الفعل السريعة.
من خلال معرفتي الأخيرة بـ BDD بالمقارنة مع TDD، يركز BDD على تحديد ما سيحدث بعد ذلك، بينما يركز TDD على إعداد مجموعة من الشروط ثم النظر إلى المخرجات.
يبدو أن التطوير المبني على السلوك يركز بشكل أكبر على التفاعل والتواصل بين المطورين وأيضًا بين المطورين والمختبرين.
تحتوي مقالة ويكيبيديا على شرح:
بالرغم من ذلك، لا أمارس BDD بنفسي.
ضع في اعتبارك أن الفائدة الأساسية لـ TDD هي التصميم.ينبغي أن يطلق عليه التصميم القائم على الاختبار.BDD هي مجموعة فرعية من TDD، أطلق عليها التصميم الموجه بالسلوك.
الآن فكر في تطبيق شائع لـ TDD - اختبار الوحدة.عادةً ما تكون الوحدات الموجودة في اختبار الوحدة جزءًا واحدًا من المنطق وهو أصغر وحدة عمل يمكنك القيام بها.
عندما تقوم بتجميع هذه الوحدات معًا بطريقة وظيفية لوصف السلوك المطلوب للآلات، فإنك تحتاج إلى فهم السلوك الذي تصفه للآلة.يركز التصميم الموجه بالسلوك على التحقق من فهم المنفذين لحالات الاستخدام/المتطلبات/أي شيء والتحقق من تنفيذ كل ميزة.يخدم BDD وTDD بشكل عام الغرض المهم المتمثل في إعلام التصميم والغرض الثاني وهو التحقق من صحة التنفيذ خاصة عندما يتغير.يتضمن تنفيذ BDD بشكل صحيح biz وdev (و qa)، في حين أن اختبار الوحدة (ربما يُنظر إليه بشكل غير صحيح على أنه TDD بدلاً من نوع واحد من TDD) يتم إجراؤه عادةً في صومعة التطوير.
أود أن أضيف أن اختبارات BDD هي بمثابة متطلبات معيشية.
BDD هو إلى حد كبير TDD يتم تنفيذه بشكل صحيح.ومع ذلك، هناك قيمة إضافية تقدمها BDD.وهنا رابط على ذلك:
وهنا لقطة سريعة:
TDD هي مجرد عملية اختبار الكود قبل كتابته!
DDD هي عملية إعلامك بالمجال قبل كل دورة من لمس الكود!
BDD هو تطبيق TDD الذي يجلب بعض جوانب DDD!
امل ان يساعد!
الفرق بين التطوير القائم على الاختبار (TDD) والتطوير القائم على السلوك (BDD)
يركز BDD على الجانب السلوكي للنظام بدلاً من الجانب السلوكي
الجانب التنفيذي للنظام الذي يركز عليه TDD.يوفر BDD فهمًا أوضح لما يجب أن يفعله النظام
من وجهة نظر المطور والعميل.TDD فقط
يمنح المطور فهمًا لما يجب أن يفعله النظام.يتيح BDD كل من المطور والعميل العمل معًا على تحليل المتطلبات الواردة في الكود المصدري للنظام.
لا يوجد فرق بين TDD و BDD.إلا أنه يمكنك قراءة اختباراتك بشكل أفضل، ويمكنك استخدامها كمتطلبات.إذا كتبت متطلباتك بنفس الكلمات التي تكتب بها اختبارات BDD، فيمكنك أن تأتي من عميلك ببعض اختباراتك المحددة الجاهزة لكتابة التعليمات البرمجية.
