ربما كل ألم يعرف هذا الألم - وثائق غير ذات صلة. بغض النظر عن مدى صعوبة الفريق ، في المشاريع الحديثة سنصدر في كثير من الأحيان أنه يكاد يكون من المستحيل وصف جميع التغييرات. قرر فريق الاختبار التابع لنا ، إلى جانب محللي النظام ، محاولة تنشيط وثائق مشروعنا.
تستخدم مشاريع الويب الخاصة بـ Alfa-Bank إطار عمل أتمتة اختبار
Akita ، والذي يستخدم لنصوص BDD. حتى الآن ، اكتسب إطار العمل شعبية كبيرة بسبب عتبة الدخول المنخفضة وسهولة الاستخدام والقدرة على اختبار التصميم. لكننا قررنا المضي قدمًا - على أساس سيناريوهات الاختبار الموصوفة لإنشاء الوثائق ، مما يقلل بشكل كبير من الوقت الذي يقضيه المحللون في المشكلة الأبدية المتمثلة في تحديث الوثائق.
في الواقع ، إلى جانب Akita ، تم استخدام مكون إضافي لتوليد الوثائق بالفعل ، والذي تخطى الخطوات الموجودة في البرامج النصية وتحميلها إلى تنسيق HTML ، ولكن من أجل جعل هذه الوثيقة شائعة ، نحتاج إلى إضافة:
- لقطات.
- قيم المتغيرات (ملف التكوين ، حسابات المستخدمين ، إلخ) ؛
- الحالات ومعلمات الاستعلام.
نظرنا إلى المكون الإضافي الموجود لدينا ، والذي كان في الواقع محللًا ثابتًا ووثائق تم إنشاؤها بناءً على البرامج النصية الموضحة في ملفات .feature. قررنا إضافة مكبرات صوت ، وحتى لا نجعل المكون الإضافي يبدو وكأنه مكون إضافي ، قررنا أن نكتب أدواتنا الخاصة.
أولاً ، قررنا معرفة كيف يمكننا جمع لقطات الشاشة وقيم المتغيرات المستخدمة في البرامج النصية للاختبار من ملفات الميزات. كل شيء اتضح أنه بسيط للغاية. الخيار ، عند تشغيل الاختبارات لكل ملف ميزة ، ينشئ cucumber.json منفصل.
داخل هذا الملف يحتوي على الكائنات التالية:
اسم حالة الاختبار والكلمة الرئيسية:
صفائف العناصر - البرامج النصية والخطوات نفسها:
يحتوي حقل الإخراج على معلومات إضافية ، على سبيل المثال ، المتغيرات - العناوين ، الروابط ، حسابات المستخدمين ، إلخ:
تحتوي الزخارف على لقطات تأخذ السيلينيوم خلال الاختبارات:
وبالتالي ، نحتاج فقط إلى الاطلاع على ملفات cucumber.json ، وجمع أسماء مجموعات الاختبار ، واختبار البرامج النصية ، وسحب الخطوات ، وجمع معلومات إضافية ولقطات الشاشة.
لكي تعرض الوثائق الطلبات التي تحدث في الخلفية أو لاتخاذ إجراء محدد ، كان علينا أن نطلب من مطورينا الأساسيين المساعدة. بمساعدة الوكيل ، تمكنا من الحصول على traceId ، الذي يولد طلبات خدمة أمامية. بواسطة traceId نفسه ، تتم كتابة السجلات في مرونة ، حيث نقوم بسحب جميع معلمات الاستعلام الضرورية في تقرير الاختبار والوثائق.
نتيجة لذلك ، حصلنا على ملف بتنسيق Asciidoc - تنسيق ملف مناسب ، أكثر تعقيدًا قليلاً من التناظرية التناظرية ، ولكن لدينا خيارات تنسيق أكثر بكثير (يمكنك إدراج صورة أو جدول ، لا يمكن القيام به في تخفيض السعر).
لتحويل Asciidoc الناتج إلى تنسيقات أخرى ، نستخدم Ascii doctorj ، وهي النسخة الرسمية لأداة Java AsciiDoctor. نتيجة لذلك ، نحصل على وثائق جاهزة بتنسيق html ، والتي يمكن تنزيلها بالتقاء ، أو إرسالها إلى زميل أو وضعها في المستودع.
كيف تتصل
الآن ، لإنشاء وثائق أمامية لمشروعك ، تحتاج فقط إلى توصيل المكوّن الإضافي للوثائق به وبعد تشغيل جميع الاختبارات ، قم بتشغيل الأمر
adoc .
ما الذي نريد تحسينه؟
- أضف خطوات فنية قابلة للتكوين.
في الإصدار الحالي من البرنامج المساعد ، توجد خطوات "وتم التقاط لقطة شاشة ...". لا تحمل هذه الخطوات عبئًا دلاليًا للتوثيق ، ونريد أن نخفيها. الآن قمنا بخياطةها داخل البرنامج المساعد ، وتم تخطيها ، ولكن هناك عيبًا - تؤدي كل إضافة من هذه الخطوة إلى حقيقة أننا بحاجة إلى إنشاء نسخة جديدة من البرنامج المساعد. للتخلص من ذلك ، نخطط لنقل هذه الخطوات إلى ملف التكوين وتدوين تلك الخطوات التي لا نريد رؤيتها في البرامج النصية. - جعل البرنامج المساعد sourse مفتوحة.
ما الفرق المناسبة لتنفيذنا؟
- استخدام الخيار (أو إطار مماثل) ؛
- ترغب في الحصول على وثائق حديثة للواجهة وقاعدة المعرفة ؛
- انهم يريدون إشراك المحللين في الاختبار.
النتيجة:
أظهر اختبار تجريبي على العديد من الفرق أنه بمساعدة المكون الإضافي الذي نجحنا في الحفاظ على تحديث المستندات ، لم يعد المحللون بحاجة إلى قضاء وقتهم في الاحتفاظ بها. بالإضافة إلى ذلك ، فإن تنفيذ هذه الميزة جعلنا نفكر في الاستمرار في تنفيذ BDD كامل ضمن فرق. اليوم ، نجري تجربة - يقوم المحللون بصياغة مسار إيجابي للعميل ، ويشيرون إلى قيود العمل باستخدام خطوات BDD الخاصة بـ Akita ، ويقوم المختبرون ، بدورهم ، بكتابة خطوات مخصصة وفحوصات إضافية لهذه السيناريوهات.
بالمناسبة ، حول holivar ، سواء كانت BDD مطلوبة أم لا ، يوم الاثنين سنعقد
اجتماعًا خاصًا .