لن يقدّر مديرك TDD: جرب مثال التطوير السلوكي هذا

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

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

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

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

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

لماذا يتم قطع الاختبار؟

هناك فجوة واضحة هنا: إذا كان صاحب العمل قد تصور سلوكيات النظام في البداية ، فلماذا يتم اختبار أن هذه السلوكيات تعمل في الواقع غالبًا الخطوة التي يتم قطعها؟

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

كيف نجري اختبارات على رأس المال المشترك ، هذه القائمة من سلوكيات النظام؟ من خلال تبني ليس فقط التطوير المدفوع بالاختبار (TDD) ، ولكن التطوير المدفوع بالسلوك (BDD).

ما هو BDD؟

يجب أن يركز التطوير المدفوع بالسلوك على سلوكيات العمل التي تنفذها التعليمات البرمجية الخاصة بك: "السبب" وراء الكود . وهو يدعم سير العمل المرتكز على الفريق (وخاصة متعدد الوظائف).

لقد رأيت BDD الرشيقة تعمل بشكل جيد حقًا عندما يجلس مطور ومالك منتج Agile أو محلل أعمال معًا ويكتبون المواصفات المعلقة (ليتم ملؤها لاحقًا بواسطة المطور) في محرر نص عادي:

1. يحدد رجل الأعمال السلوكيات التي يريدون رؤيتها في النظام.
2. يطرح المطور أسئلة بناءً على فهمه للنظام ، بينما يقوم أيضًا بتدوين السلوكيات الإضافية المطلوبة من منظور التطوير.

من الناحية المثالية ، يمكن للطرفين الرجوع إلى قائمة سلوكيات النظام الحالية لمعرفة ما إذا كانت هذه الميزة الجديدة ستكسر الميزات الحالية.

لقد وجدت أن هذا الفعل البسيط يعطيني قيودًا كافية يمكنني التفكير بها كمطور: "نظرًا لضرورة تنفيذ هذه الاختبارات ، كيف يقيد ذلكني / كل شخص في المواصفات التي يمكنني تنفيذها في التعليمات البرمجية"؟ نظرًا لأنها مواصفات معلقة ، فهي سريعة وسهلة الكتابة في خضم التعاون.

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

دعنا نرى مثالاً على التنمية المدفوعة بالسلوك

السيناريو: أنت مطور في فريق مسؤول عن نظام محاسبة الشركة ، المطبق في ريلز. في أحد الأيام ، يطلب منك رجل أعمال تنفيذ نظام تذكير لتذكير العملاء بفواتيرهم المعلقة. لأنك تمارس BDD لكل هذا التدريس ؛ (مقابل TDD) ، تجلس مع رجل الأعمال هذا وتبدأ في تحديد السلوكيات.

تفتح محرر النصوص وتبدأ في إنشاء مواصفات معلقة للسلوكيات التي يريدها مستخدم الأعمال:

 it "adds a reminder date when an invoice is created" it "sends an email to the invoice's account's primary contact after the reminder date has passed" it "marks that the user has read the email in the invoice"

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

يفضل بعض المطورين كتابة حالات الاختبار على الفور ، وطرق الاتصال في النظام ، وإعداد التوقعات ، مثل:

 it "adds a reminder date when an invoice is created" do current_invoice = create :invoice current_invoice.reminder_date.should == 20.days.from_now end

ستفشل مجموعة الاختبار لأننا لم نكتب الرمز بعد لتعيين reminder_date .

المواصفات الفاشلة وجهاً لوجه

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

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

كيف يختلف BDD عن TDD؟

دعنا ننظر إلى هذا بطريقة مختلفة ، باستخدام نهج التطوير المستند إلى الاختبار ، وكتابة الاختبارات المعلقة:

 it "after_create an Invoice sets a reminder date to be creation + 20 business days" it "Account#primary_payment_contact returns the current payment contact or the client project manager" it "InvoiceChecker#mailer finds invoices that are overdue and sends the email"

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

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

لقد بذل الكثير من العمل في مجتمع BDD في جعل فحوصات التأكيد داخل الاختبار تُقرأ مثل اللغة الإنجليزية. إليك اختبار RSpec النمطي:

 a = 42 a.should == 42

هذا التنسيق يجعل الأمور أسهل للقراءة لاحقًا. لكن تذكر أن هذا ليس ما نقوم به هنا - الهدف هو تقليل السلوكيات بأسرع ما يمكن - وفرض مبدأ "سلوك واحد تم اختباره لكل المواصفات". من الناحية المثالية ، يجب أن يخبرك عنوان المواصفات المعلقة بما تختبره.

لا يتعلق BDD بالطرق الفاخرة للتحقق من صحة نتائجك ؛ يتعلق الأمر بمشاركة السلوكيات المتوقعة بين جميع أعضاء الفريق.

التنمية المدفوعة بالسلوك تدور حول التعاون والتواصل

لنعد إلى السيناريو الخاص بنا: العمل على نظام محاسبة الشركة.

أنت تمشي من خلال وظائف العنصر مع رجل الأعمال ، حيث تقوم بتحليل النظام من خلال الأجزاء الداخلية (كيف تتلاءم الكائنات معًا داخليًا) ، ويقومون بتحليل النظام من الخارج.

تفكر في بعض الشروط وتسأل محلل الأعمال عما يحدث في السيناريوهات التالية:

 * What's the default reminder date going to be? How many days before the invoice due date? * Are those business days or just calendar days? * What happens if there's not a primary contact associated with the account?

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

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

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

إنه أيضًا موقف جيد عندما لا يكون عميل Agile موجودًا فعليًا في الغرفة بعد الآن: أن تكون رغباتهم على الورق ، ممزوجة بتحليل المطور (والترجمة) لما تقوم ببنائه.

وثائق التصميم

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

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

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

التنمية المدفوعة بالسلوك تدور حول القطع الأثرية المشتركة

ما هي الأداة المشتركة؟

أحب أن أفكر في "القطع الأثرية" في هندسة البرمجيات على أنها أشياء مادية محتملة تصف المشروع أو فريق المشروع ، ويمكن العثور عليها بعد ستة أشهر. تشرح المصنوعات اليدوية الجيدة سبب كون الأشياء على ما هي عليه.

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

الأداة هي بعض التعليمات البرمجية المصدر المحفوظة في مستودع أو مساحة مشتركة ، وتذاكر في نظام التذاكر ، أو ملاحظات على Wiki الداخلي - أو حتى سجلات الدردشة المستمرة.

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

كيف تستخدمها في BDD؟

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

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

هذا الفهم على مستوى الشركة لما يفعله النظام هو شكل من أشكال رأس المال أيضًا. إنه "لماذا" في الكود "كيف".

خاتمة

كيف نحل مشكلة برامج عربات التي تجرها الدواب التي يتم تسليمها للعملاء؟ من خلال التأكد من عدم اعتبار الاختبار شيئًا "يهتم به المطورون فقط".

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