يستخدم المبرمجون اليوم المزيد والمزيد من الممارسات الرشيقة في عملهم اليومي. حتى المشاريع التي تتبع دورة حياة تطوير البرمجيات القياسية يمكن أن تستفيد من تكييفها. فالاختبار التلقائي وممارسات تطوير البرمجيات TDD أضفت المزيد من الثقة على عملنا، وسهلت تنفيذ التعديلات على الميزات الموجودة وغالباً ما تقودنا إلى تصميم أفضل للكود. ولكن هذا لا يكفي الآن. علينا أن ندفع بالفوائد من الاختبارات إلى أقصى الحدود، ويسمح لنا الاختبار التلقائي للتطوير البرمجي (BDD) بذلك، حيث يبني BDD على رأس TDD ويضيف إلى ممارساته الكثير من القيمة. فهو يجلب اللغة في كل مكان للمشروع، ويسمح بتواصل أفضل بين العميل والمطورين. إنه يقدم الكثير لمديري وقادة المشاريع، ولكنه أيضًا يجعل حياة المطور أسهل كثيرًا. فاتباع مبادئ BDD يعطينا متطلبات واضحة، والاختبارات أسهل للفهم ويمكن أن تكون بمثابة وثائق. يحول BDD تركيز مواضيع الاختبار ويمنحنا الثقة بأننا نختبر ما يجب أن نختبره - السلوك.
إذا كنت تستخدم TDD، فسيكون البدء بـ BDD أمرًا سهلاً - فهو في الأساس مجموعة من أفضل الممارسات الخاصة به. يحتوي BDD على مجموعة من القواعد البسيطة، والتي توضح كيفية كتابة المواصفات وما يجب اختباره. تنقسم المواصفات إلى ثلاثة أجزاء: معطى (إعداد شروط الاختبار)، ومتى (استدعاء الإجراء على الموضوع) وثم (التأكيدات). يجب أن يكون للاختبارات أسماء وصفية، وتسمح أطر الاختبار الحالية باستخدام أساليب وتأكيدات مشابهة للغة الطبيعية - وكلها مجتمعة تعطينا اختبارات يمكن قراءتها من قبل المستخدمين التقنيين وغير التقنيين على حد سواء. تثبت اصطلاحات التسمية الجيدة فائدتها أثناء اختبارات الانحدار.
يأتي BDD أيضًا مع مجموعة من الإرشادات لموضوعات الاختبار. وعلى النقيض من TDD، فإنه يحول التركيز من اختبار التنفيذ إلى اختبار السلوك - ويؤدي استخدام ذلك إلى تصميم أفضل ويمنح مرونة أكبر عند الحاجة إلى إدخال تغيير. يجب أن تكون المواصفات مثل متطلبات العميل المكتوبة والقابلة للتنفيذ - يجب أن تكون المواصفات عالية المستوى بمثابة اختبارات قبول. الهدف هو كتابة الاختبارات بطريقة تحتاج إلى تغييرها فقط عندما تتغير المتطلبات. يمنحنا استخدام BDD الثقة بأننا نختبر ما يجب تغطيته بالفعل وهو نهج أكثر واقعية من TDD.
إذا كنت ترغب في رؤية BDD في العمل، نوصي باستخدام روبي. إنها لغة قوية وممتعة للاستخدام ولديها مجموعة أدوات ممتازة للتطوير البرمجي الثنائي، وهي لغة قوية وممتعة.
الخيار
Cucumber هو الإطار الأكثر شيوعًا لـ BDD في روبي. يقدم لغة خاصة تسمى Gherkin، والتي ستكتب بها اختباراتك. على النقيض من RSpec، فإن الميزات الموصوفة في Gherkin هي نص عادي وليس الكود، وعلى هذا النحو يمكن - ويجب - أن يفهمها أي شخص، وعلى الأخص العميل.
تبدو ميزة الخيار هكذا (مثال مأخوذ من ويكي الخيار):
الميزة: نص مقتضب ولكنه وصفي لما هو مرغوب فيه
وصف نصي للقيمة التجارية لهذه الميزة.
قواعد العمل التي تحكم نطاق الميزة
أي معلومات إضافية من شأنها تسهيل فهم الميزة.
السيناريو: بعض حالات العمل التي يمكن تحديدها
بالنظر إلى بعض الشروط المسبقة
وبعض الشروط المسبقة الأخرى
عند بعض الإجراءات التي يقوم بها الممثل
وبعض الإجراءات الأخرى
وفعل آخر
ثم تتحقق بعض النتائج القابلة للاختبار
وشيء آخر يمكننا التحقق من حدوثه أيضًا
سيناريو موقف مختلف
...
سيتم وصف الميزات لاحقاً بالتفصيل.
استخدام الخيار في Ruby on Rails
التركيب
الخطوة الأولى لاستخدام الخيار في المشروع هو تثبيته. فقط أضف هاتين الجوهرتين إلى ملف Gemfile الخاص بك:
المجموعة :test do
جوهرة 'قضبان الخيار'، :يتطلب => خطأ
جوهرة 'منظف_قاعدة_البيانات'
إنهاء
قم بتجميعها عن طريق تشغيل تثبيت الحزمةوإنشاء نصوص Cucumber النصية والدلائل باستخدام الأمر التالي:
القضبان توليد خيار القضبان: تثبيت
سيؤدي ذلك إلى إنشاء التكوين/خيار.yml, البرنامج النصي/الخيار و الميزات/الدليلوالتي ستحتوي على الميزة بالإضافة إلى تعريفات الخطوات والملفات الداعمة. لتشغيل الميزات الخاصة بك، استخدم أمر rake الجديد:
خيار أشعل النار
الميزات
دعنا نلقي نظرة فاحصة على الميزات. الميزة هي شيء يمتلكه أو يفعله تطبيقك - على سبيل المثال إرسال رسائل إخبارية بشكل دوري أو السماح للمستخدم بمشاركة صوره بشكل عام. تتكون الميزة الواحدة من سيناريوهات متعددة تصف كيفية عمل هذه الميزة في سياقات مختلفة.
لتوضيح الاستخدام الأساسي لـ Cucumber في Rails، سنكتب ميزة من الصفر. سيكون هذا المثال الميزة الأولى التي سنكتبها في التطبيق، والتي ستظهر في الجزء الثاني القادم من هذه المقالة. سيسمح هذا التطبيق للمستخدم بإنشاء سلع ومتاجر (متاجر تبيع السلع) ثم إنشاء قوائم تسوق.
في أبسط إصدار، بعد تجميع قائمة التسوق، سيُظهر التطبيق المتاجر التي تكون فيها السلع التي يريدها المستخدم هي الأرخص.
أولاً، قم بإنشاء ملف جديد باسم إنشاء_عنصر.ميزة في الميزات/ الدليل. في الجزء العلوي من الميزة يوجد ملف الميزة كلمة رئيسية، متبوعة بوصف موجز لها. على سبيل المثال:
الميزة: إنشاء العناصر
في السطور التالية يمكنك كتابة هدف العمل الذي سينفذ هذه الميزة. نظرًا لأن Cucumber يتجاهل النص المكتوب قبل السيناريو الأول، فليس من الضروري كتابة أي شيء، لكنها بالتأكيد فكرة جيدة.
من أجل إنشاء قوائم تسوق بسهولة مع العناصر المباعة في المتاجر القريبة
كمستخدم
أريد إضافة عناصر إلى النظام
في المقتطف، يمكنك رؤية نمط شائع جدًا أعلاه يمكنك من خلاله وصف أهداف العمل. وهو يتألف من ثلاثة أجزاء: لماذا الميزة ضرورية، ومن يريدها، وما هي. بالطبع، ليس عليك اتباع هذا النمط، لكن احرص على تضمين إجابات هذه الأسئلة الثلاثة في وصفك.
السيناريوهات
بعد ذلك، نكتب بعض السيناريوهات. يبدأ كل سيناريو بالكلمة الرئيسية "سيناريو" ويحتوي على عدة خطوات.
السيناريو: إنشاء عنصر فريد
بالنظر إلى وجود عنصر "حليب"
عندما أذهب إلى الصفحة الرئيسية
وأنشئ عنصر "خبز"
ثم أرى "خبز" في قائمة العناصر
لذا، إذا أنشأ شخص ما صنفًا باسم الحليب، فإن إنشاء الخبز ممكن وينتج عنه ظهور الخبز في قائمة الأصناف. لا ينبغي لنا اختبار إنشاء سجل في قاعدة البيانات، لأن هذه الحقيقة ليس لها قيمة حقيقية للعميل.
تستخدم خطوات السيناريو ثلاث كلمات رئيسية:
معطىلتوفير السياق للسيناريو
عندمالوصف الإجراءات
ثملوصف النتائج
من المهم ملاحظة أن الخيار يتجاهل خطوة الكلمة المفتاحية التي يبدأ بها ويطابق فقط الجزء اللاحق. وبالتالي، يمكنك أن تبدأ خطواتك بـ "و" أينما كان ذلك طبيعيًا. القاعدة الوحيدة لاختيار الكلمة المفتاحية المناسبة هي أن السيناريو يجب أن يكون مفهومًا بسهولة.
تعريفات الخطوة
ينتج عن تشغيل الخيار الآن هذا الإخراج:
[...]
الميزة: إنشاء العناصر
من أجل إنشاء قوائم تسوق بسهولة مع العناصر التي تباع في المتاجر القريبة
كمستخدم
أريد إضافة عناصر إلى النظام
السيناريو: إنشاء عنصر فريد # ميزات/إنشاء_عنصر.ميزة:6
بالنظر إلى وجود عنصر "حليب" # ميزات/إنشاء_ميزات_ميزات.7
خطوة غير محددة: "يوجد عنصر "حليب" (الخيار::غير معرف)
[...]
هذا لأن الخيار لا يعرف ما نعنيه عندما نقول "يوجد عنصر حليب". لإضافة بعض المعنى لخطواتك تحتاج إلى تعريفها في التعريفات_التدرجية الدليل.
الطريقة الموصى بها لتنظيم تعريفات خطواتك هي تقسيمها حسب المجال. على سبيل المثال، معظم الخطوات التي أنشأناها، تنتمي إلى مجال العنصر. وبالتالي، يجب أن ننشئ ملفًا باسم step_definitions/item_steps.rb ووضع الرمز التالي هناك:
بالنظر إلى "وجود عنصر "$name" افعل |الاسم |
تصنيع :العنصر، الاسم: الاسم
النهاية
عندما "أقوم بإنشاء عنصر "$name" أفعل |الاسم |
داخل "#new_item" do
ملء_في "الاسم"، مع: الاسم
انقر على "إنشاء"
إنهاء
إنهاء
ثم "أرى "$name" في قائمة العناصر" افعل |الاسم|
ضمن ".العناصر" تفعل
توقع (الصفحة).أن يكون لها_اسم_محتوى
النهاية
النهاية
عادةً ما تعتمد تعريفات الخطوات على كابيبارا. إذا لم تكن على دراية بكابيبارا، تأكد من مراجعة الروابط في نهاية هذه المقالة.
هناك خطوة أخرى تحتاج إلى تعريف ولا تتناسب مع خطوات البند. يمكنك وضعها في main_page_steps.rb:
عندما "أذهب إلى الصفحة الرئيسية" قم بـ
زيارة جذر_المسار
النهاية
الخاتمة
هذه قصة بسيطة جدًا لميزة بسيطة جدًا. كان الغرض منها هو توضيح المفاهيم الأساسية ل BDD كما هي مستخدمة في Cucumber. لكن كتابة القصص الجيدة تتطلب أكثر من ذلك بقليل. كمطور، ستحتاج كمطور إلى تغيير طريقة تفكيرك بالكامل - انسَ التنفيذ وركز على أهداف العمل بدلاً من ذلك. يجعل Cucumber هذا الانتقال أسهل من خلال استخدامه الذكي للقصص النصية البسيطة.