BDD - التنمية من خلال السلوك. BDD for microservices هو تعاون من قبل العميل والمطورين والمختبرين. BDD هو تطور يأخذ في الاعتبار المصالح الفنية ومتطلبات العمل. عادةً ما يتم استخدام هذا النهج لوصف واجهات التطبيق ، وبما أن الخدمات الميكروية هي تفاصيل تطبيق النظام ، فإن BDD مناسب أيضًا لتطوير الخدمات الصغيرة. كيف نفعل ذلك - في ترجمة كين بوغ.
نبذة عن الكاتب: كين بوغ يعلم الشركات تطوير المرونة ، وإنشاء أنظمة عالية الجودة باستخدام تسريع قبول اختبار التنمية ، BDD ، تسريع DevOps. كتب كين العديد من الكتب حول تطوير البرمجيات ، وقد فاز بجائزة Jolt Award 2006 Prefactoring ، أحد المبدعين لدورة SAFe Agile Software Engineering.
غالبًا ما يتم التعبير عن السلوك في BDD بواسطة البناء المعطى / عندما / ثم. يتم منحنا حالة معينة عند حدوث إجراء أو حدث ، ثم تتغير الحالة و / أو يتم إرجاع المعلومات.
على سبيل المثال ، يصف المنطق عديم الجنسية ، مثل قواعد الأعمال والحسابات ، ببساطة تحويل المدخلات إلى المخرجات.
يستخدم التصميم الموجه
للواجهة مبدأ
"التصميم للواجهات ، وليس للتطبيقات" . يستخدم مستهلكو الخدمة الواجهة التي توفرها ، وليس الواجهة الداخلية. هذا يعني أنه يجب التفكير بوضوح في مثل هذه الواجهة ، بما في ذلك سلوك الخطأ. لتعريف المصطلحات في وصف الواجهة أو سلوكها ، من الممكن استخدام تصميم DDD - Domain Driven Design.
يمكن أن تكون Microservices متزامنة عندما يتصل المستهلك
مباشرة بخدمة أخرى ويتوقع النتيجة ، أو غير متزامن عندما
تجيب الخدمة على رسالة وضعها العميل في قائمة الانتظار .
النظر في مثال لخدمة متزامنة.
خدمة متزامنة
تخيل خدمة تحسب خصمًا على أمر مبيعات ، العملية برمتها عبارة عن مجموعة من العمليات ذات الصلة.
يمكن وصف سلوك هذه الخدمة على النحو التالي:
Get discount for a customer Given these inputs Customer category Order Amount Then service outputs Discount Amount
يمكن للخدمة حساب الخصم باستخدام خوارزميات في الكود ، بناءً على قاعدة بيانات البيانات المحلية أو عن طريق الاتصال بخدمات أخرى.
يمكنه استخدام JSON أو XML كتنسيق للرسائل. ومع ذلك ، فإن وصف الخدمة دون تحديد تفاصيل التطبيق يساعد على فصل دلالات العمليات عن بناء الجملة.
ما هو السلوك؟
باستخدام BDD ، يمكنك البدء في التصميم باستخدام نموذج البيانات للحصول على فكرة عن السلوك المطلوب. يمكن لمطوري الخدمة والعميل واختبار الخروج بهذا المثال. أول عمودين هما الإدخال إلى الخدمة ، والعمود الموجود على اليمين هو الإخراج.
يوضح المثال مصطلحات المجال التي قد تتطلب المزيد من الصقل - على سبيل المثال ، وصف القيم الصحيحة.
من المعلوم أن الخدمة تُرجع النتيجة الصحيحة إذا كانت بيانات الإدخال تدخل في نطاق القيم المقبولة.
غالبًا ما يشتمل وصف السلوك ، وخاصةً فيما يتعلق بالخدمات المصغرة ، على ردود في حالة حدوث حالات فشل أو أخطاء. إن وصف حالات الفشل المحتملة يساعد المستهلك على فهم ما يجب القيام به في مثل هذه الحالات. يمكن لعملاء الخدمة استخدام مكتبات خاصة ، على سبيل المثال ، Hystrix من Netflix ، لإصلاح بعض هذه الإخفاقات.
بعض الأخطاء المحتملة في خدمتنا:
يمكن التعبير عن الأعطال باعتبارها ثوابت رقمية أو شخصية في بروتوكول الاتصال.
يساعد استخدام أسماء ذات معنى في BDD على التأكيد على دلالات الفشل ، وليس بناء الجملة.
إذا كانت القيمة التي تم تمريرها كفئة غير مدرجة في قائمة القيم المقبولة ، فستقوم الخدمة بإرجاع مؤشر فشل: "القيمة غير صالحة لمعلمات الاستعلام". يمكن تمثيل ذلك ، على سبيل المثال ، من خلال إرجاع كود HTTP 400 ووصف النص المقابل.
بدلاً من ذلك ، يمكنك تحديد قيمة الخصم التي سيتم إرجاعها ، على سبيل المثال ، 0 إذا كانت أي من المعلمات غير صحيحة. في هذه الحالة ، يجب أن تكون الخدمة مسؤولة عن تسجيل هذه المشكلة حتى يمكن تحليل نتائجها.
يمكن أن تشكل اختبارات BDD للخدمة سياقًا لاختبارات وحدتها. في عملية التصميم ،
تقع مسؤولية اجتياز اختبارات BDD على الطبقات والأساليب . اختبارات وحدة تحديد هذه المسؤوليات.
المقابس
عند اختبار إحدى الخدمات ، غالبًا ما تكون هناك حاجة إلى دعائم الخدمات التابعة التي تدعو إليها. هناك حاجة خاصة لخدمات بطيئة ، باهظة الثمن أو عشوائية. إذا لم يتغير سلوك خدمة الخصم أبدًا ، فعند اختبار العميل ، يمكنك استخدام مثيل القتال.
التغيير غالبًا ما يكون أمرًا لا مفر منه ، لذلك عادة ما تكون هناك حاجة إلى كعب الروتين.
يمكن أن يقوم كعب الروتين دائمًا بإرجاع نفس القيم ، على سبيل المثال:
يمكن أن تعتمد اختبارات العملاء على هذه القيم. في هذا المثال ، قد يكون السلوك الثابت كافيًا. بالنسبة للاختبارات الأخرى ، يفضل استجابة كعب الروتين المخصص.
بدلاً من ذلك ، يمكن ببساطة أن يعيد كعب خدمة الخصم نفس المبلغ ، بغض النظر عن الإدخال.
كيف يمكن أن يتناسب هذا كعب الروتين مع سيناريو أوسع؟ النظر في سلوك النظام لطلب ، والذي يتضمن كل من الخصم والضريبة. يتم احتساب الضريبة بواسطة microservice ، على غرار الخصم.
هناك مشتر.
خصم قابل للتعديل.
وضعت الضريبة.
عندما يضع العميل طلبًا:
ثم طلب الخيارات.
الخدمات مع الدولة
إذا كانت خدمة الخصم تستخدم قاعدة البيانات للحصول على معلومات لحساب الخصم ، فإن محتوياتها هي حالة الخدمة. يجب توثيق التغييرات التي تم إجراؤها على الاستجابة لتحديثات البيانات. لنفترض أن الخدمة لديها هذه الحالة.
في هذه الحالة ، يجب أن تسمح الخدمة بتغيير هذه البيانات. يمكن تنظيم التحديث بحيث يتم تحديث العناصر الفردية أو تحديث الجدول بالكامل على الفور. فيما يلي مثال للاختبار السلوكي للتحديث الفردي.
إعطاء البيانات الحالية.
عندما يتم تحديث عنصر.
ثم تحديث البيانات.
يمكنك أيضًا التحقق من استخدام البيانات المحدّثة لحساب الخصم.
قد يكون لخدمة الخصم تخزين محلي لحفظ البيانات في هذا المثال ، ولكن قد يعتمد أيضًا على خدمة تخزين منفصلة لهذه البيانات. إذا كان الأمر كذلك ، فإن الاختبارات الواردة في القسم السابق تنطبق على خدمة منفصلة. لكن كل إدمان يضيف مشاكل. ماذا يجب أن يكون سلوك الخدمة إذا كانت التبعيات غير متوفرة؟ بالنسبة إلى خدمة الخصم ، هل يجب أن يشير هذا إلى فشل أم أنه يجب ببساطة إرجاع القيمة الافتراضية ، هي نفس القيمة 0؟ في بعض الأحيان ، يمكنك استخدام سياسات معالجة الأخطاء العالمية ، لكن
غالبًا ما يعتمد القرار على سياق الخدمة .
صياغة الاختبار والأتمتة
بمجرد أن يكون سلوك microservice ثابتًا ، يمكن صياغته بمثابة اختبارات آلية. هناك العديد من أنظمة اختبار الخدمات المصغرة ، مثل PACT أو الكاراتيه. بالإضافة إلى ذلك ، يمكنك استخدام أطر عمل BDD مثل الخيار أو FIT.
على سبيل المثال ، يستخدم Cucumber المكتبات للاستعلام عن الخدمات. ثم يمكن تقديم معلومات إضافية حول البيئة كجزء من البرنامج النصي.
على سبيل المثال ، قد يتضمن ملف كائن Cucumber.
تعتمد خيارات الخطوة على اصطلاحات الاختبار الخاصة بك.
يمكن نقل القيم الموجودة في العمودين الأولين إلى أي اصطلاح استدعاء ، على سبيل المثال ، إلى معلمات الاستعلام. يجب أن تتطابق النتيجة في النص مع العمود الثالث. إذا كانت أسماء وقيم الاستعلام هي أسماء وقيم الأعمدة ، فإن هذا يقلل من الاختلافات بين الاختبار والتنفيذ.
لإعادة الاستخدام ، يمكن كتابة الخطوات لخدمة تعسفية تقوم بإجراء عمليات حسابية أو تحدد نتيجة قاعدة العمل. في المثال أعلاه ، فإن استخدام الرمز "؟" ، كما في "مبلغ الخصم" أعلاه ، يساعد المحلل على التمييز بين المدخلات والمخرجات.
يجب أن تشمل الاختبارات أيضًا الإخفاقات ، على سبيل المثال.
استنتاج
تعتمد خدمات Microservices على خدمات وأنظمة أخرى ، مما يتطلب تحديدًا واضحًا للواجهات واختبارها الدقيق. يمكن تحقيق ذلك من خلال وصف السلوك والواجهات التي تحددها الاختبارات. باستخدام BDD ، يتم وصف وظيفة الخدمة باختبارات قابلة للتنفيذ تركز
على دلالات العمليات ، بدلاً من بناء الجملة . عادةً ما تتطلب أتمتة مثل هذه الاختبارات إعداد بذرة من الخدمات الأخرى ، والتي يوصف سلوكها من خلال اختبارات BDD الفردية الخاصة بها.
يتضمن التصميم الموجه نحو الواجهة - IOD ، التزامات إضافية للخدمة: تقييد استخدام الموارد وعرض النطاق الترددي والإبلاغ عن الأخطاء. يساعد كل من BDD و IOD معًا في وصف سلوك الخدمة بحيث يمكن للعملاء فهمها والاعتماد عليها بسهولة.
- يركز BDD for microservices على تعاون الثالوث - مطور الخدمة ومطور العميل واختباره.
- إنشاء اصطلاحات محددة بوضوح لواجهات microservice باستخدام IOD.
- تتطلب خدمات Microservices مقابس اختبار لتسريع الاختبار.
- يجب أن تكون الاختبارات مستقلة.
- اختبار السيناريوهات السلبية في الاختبارات.
في الفترة من 27 إلى 28 مايو ، خلال مهرجان RIT ++ ، في مؤتمر QualityConf ، ستتحدث Artyom Malyshev عن أهمية التعبير بوضوح عن نموذج المجال في الكود وإظهار كيفية القيام بذلك باستخدام الأمثلة.
تعال وتحدث عن تطوير منتجات عالية الجودة وشارك أفكارك!