في مقال سابق ، شاركت تجربتي في الأتمتة في إطار الروبوت. الآن سنتحدث عن نهج مختلف قليلاً لاختبار واجهة برمجة التطبيقات لمشروع على Kotlin.
استفدت من حرية اختيار مجموعة التكنولوجيا والاعتماد على الرغبة في تجربة شيء جديد "في المعركة" ، لجأت إلى الراحة. لقد قمت ، وزملائي ، بإجراء بعض الاختبارات ليس بدون بعض الصعوبات ، ونتيجة لتطوير النهج ، قمنا بتسجيله في قائمة المهام الرئيسية لهذا النوع من المهام.
(الصورة تستخدم محاكاة ساخرة)بدأ كل شيء بحقيقة أنه تم تلقي طلب لأتمتة اختبار واجهة برمجة التطبيقات في أحد المشاريع الجديدة في
قطاع Ad-tech . لقد فعلنا مدير الحملة و DMP والعديد من عمليات الدمج مع أنظمة الجهات الخارجية. وكان للمختبرين مهمة بسيطة للغاية: لأتمتة اختبار الدخان لمزيد من التكامل في CI والمراقبة المستمرة لحالة واجهة برمجة التطبيقات هذه ، نظرًا لأن أنظمة الجهات الخارجية مرتبطة بها والتشغيل الصحيح أمر بالغ الأهمية. لم يكن التحقق من منطق الأعمال في هذه الحالة مطلوبًا ، لأن الخدمة المختبرة هي في الأساس واجهة وكيل.
لماذا تطمئن؟
من وجهة نظر التشغيل الآلي للاختبار ، تمكنا من العمل في مجموعة متنوعة من المجالات - واجهة المستخدم ، الويب ، الهاتف المحمول ، سطح المكتب ، الواجهة الخلفية ، REST API ، SOAP.
لقد منحنا
المشروع السابق الكثير من الخبرة في إطار الروبوت ، لذلك سيكون من المنطقي جدًا استخدامه. معظم فريق الاختبار على دراية به ، وإذا كان هناك حاجة إلى استبدال عاجل ، فسيتم ذلك بسرعة وبدون ألم تقريبًا. ولكن تم اتخاذ قرار مختلف.
أولاً ، تم كتابة المشروع نفسه في Kotlin وتم بناؤه باستخدام Gradle. في الوقت نفسه ، في مرحلة التصميم ، تقرر أن الاختبارات الذاتية لم تخصص مشروع منفصل. كما لوحظ في التعليقات على المقالة السابقة ، فإن التمسك بجافا (Kotlin) وإطار عمل الروبوت هو ألم كبير ، لذلك لم يكن هناك أي فائدة من الإشارة إلى RF. بالإضافة إلى ذلك ، بالنظر إلى العمل مع الروبوت ، كنت مهتمًا بتجربة نهج مختلف. علاوة على ذلك ، يمكننا في هذا المشروع اختيار مجموعة تكنولوجيا بشكل مستقل - لم تحدد الشركة شروطها الخاصة.
بحثًا عن الأفكار ، لجأت إلى فريق التطوير لدينا ، بالإضافة إلى الزملاء من الاختبار ، ونصحتني CTO بالنظر إلى Rest-Assured (
rest-assured.io ). بعد أن قرأت التوثيق واختبارات العينة في مصادر مفتوحة ، بدا لي النهج الذي اقترحه Rest-Assured جذابا للغاية بالنسبة لي. هذا يعني تلقي استجابة من الواجهة الخلفية في شكل JSON ، والتي نرغب في تحويلها إلى كائنات Java قديمة جيدة.
علاوة على ذلك ، باستخدام هذا الهيكل ، يمكنك العمل كما هو الحال مع كائن عادي. ونتيجة لذلك ، لدينا نهج طبيعي كائني التوجه نحو التحقق من صحة المراسلات الخاصة باستجابة API لبنية الكائن الموصوفة. كمكافأة ، نحصل على اختبار سريع للخلل في بنية الاستجابة - إذا كان الكائن الذي تم تلقيه عن طريق إلغاء تسلسل استجابة API يختلف في عدد الحقول أو أسمائها ، فستنخفض الاختبارات قبل التحقق من البيانات مع وجود خطأ في إلغاء التسلسل. لذلك سوف نفهم ما إذا كنا بحاجة إلى إصلاح الواجهة الخلفية أو تحديث الاختبارات وفقًا لمتطلبات API الجديدة. في حالتنا ، كان هذا مهمًا ، كما ذكرت أعلاه ، ترتبط العديد من الأنظمة الفرعية التابعة لجهات خارجية بواجهة برمجة التطبيقات.
من أجل الدقة ، ألاحظ أنه يمكن الحصول على نفس الاختبار المعطل تقريبًا على التردد اللاسلكي ، ولكن بطريقة مختلفة قليلاً. ومع ذلك ، فإن القصة اليوم ليست حول ذلك. شخصياً ، كان من الأسهل بالنسبة لي أن أدخل من جانب Rest-Assured مع كيان لديه مجالات وأساليب معينة.
اختبار الريشة
قبل البدء في استخدام المكدس في مشروع حقيقي ، قررت تجربته على خدمة CRUD صغيرة. لكي لا يمارس أخطائه على الفور ، قرر البحث عن أفضل الممارسات في هذا المكدس وعثر بسرعة
على مقالة بقلم فيليب هاور ، حيث عكس تجربته في الأتمتة على Rest-Assured. بعد دراسة المقالة ، لم يكن من الصعب كتابة نسخة عمل من اختبارات خدمتي. تبين أنها بسيطة وسهلة القراءة والفهم.
للمعركة!
بدأ المشروع ، وعندما تم وصف هياكل الاستجابة الأولى ، بدأ إعداد وثائق الاختبار وكتابة الاختبارات الذاتية. لفهم الصورة الكبيرة ، سأقدم مجموعة كاملة من الاختبارات التلقائية:
- جافا
- JUnit4 - تنفيذ وتوصيف نصوص الاختبارات (تعليق قياسي @ Parametrize) ،
- اطمئن - بناء وتنفيذ الاستفسارات ،
- AssertJ - التحقق من صحة القيم المستلمة ،
- جاذبية - مبنى التقارير ،
- Gradle - التجميع
- جاكسون - نزع التسلسل.
عندما كتبت الاختبارات الأولى ، أصبحت مشكلة تحديد المعايير المناسبة واضحة. يبدو أن نقل القيم البسيطة للبيانات والنتيجة المتوقعة غير فعال للغاية وقبيح للغاية. لم يكن لدي الوقت لحل هذه المشكلة قبل العطلات ، لكن زملائي ، الذين شاركوا أثناء غيابي ، قاموا بتسويتها. من أجل الحصول على معلمات جميلة وسهلة القراءة ، قرروا إنشاء فئة أساسية مع وظائف إضافة معلمات الكائن واستلامها وحذفها ، والتي ورثت منها جميع الفئات التي تم استخدام كائناتها لاستدعاء أساليب API المقابلة.
هذا سمح حرفيا على الطاير لإنشاء البيانات اللازمة ونقلها في معلمات الاختبار.
يتيح لك Rest-Assured إلغاء تسلسل الاستجابة للفئة المطلوبة. تتحلل الإجابة الناتجة إلى بنية معروفة سابقًا باستخدام جاكسون. تبدو فئات إزالة التسلسل بسيطة بقدر الإمكان - يتم وصف جميع الحقول المتوقعة بأنواعها.
علاوة على ذلك ، يستمر العمل البسيط مع الأشياء وتأكيد مجالات محددة وقيمها.
الشيء الأكثر صعوبة وغير الواضح الذي صادفته في هذا النهج هو عدم القدرة على تمرير قيمة فارغة إلى Rest-Assured كأحد المعلمات (النتيجة هي انخفاض في NullPointerException). على ما يبدو ، هذه مشكلة معروفة ، لكن المطور لن يقوم بتصحيح الموقف ، ويوصي إما بإرسال الحقل فارغًا أو عدم إرساله على الإطلاق. لقد واجهنا هذه المشكلة بالفعل في المرحلة عندما كان أساس المشروع جاهزًا وبقي فقط لإضافة فئات اختبار. لذلك ، قمنا بتصحيح رمزنا قليلاً.
بشكل عام ، أحببت هذا النهج. من الغريب أنه بعد مرور بعض الوقت بدأ تطبيقه على مشروع عميل آخر (وإن لم يكن من توريدنا). ووضعنا المجموعة المجمعة لاختبار واجهات برمجة التطبيقات لاختبار الأتمتة (JUnit + AssertJ + Rest-Assured) في فئة المفاتيح الرئيسية لمشاريع Java / Kotlin. في بايثون ، سيكون سحبه معادٍ للحدس ، لأنه من الأفضل أن تتداخل كفاءات التطوير والاختبار.
من الجدير بالذكر أيضًا أن إحدى مزايا هذا الحل هي قابليته للتوسع والتكيف مع المنطق المعقد. وهذا يعني أنها الأنسب للمشاريع الجادة حيث يكون من المنطقي حقًا وصف الأشياء الكبيرة ، وتنظيف الكود وهندسة الكتلة ، عندما تكون هناك أجزاء منفصلة مسؤولة عن إعداد البيانات وإرسالها واستلامها في شكل قابل للقراءة ، وكذلك التحقق لاحقًا من البيانات للامتثال بعض الشروط. في المشاريع الصغيرة ، كل هذا لا معنى للسحب.
الملخص
في غضون شهر تقريبًا ، تمكنا من أتمتة حوالي 250 اختبارًا وتوفير مستوى التغطية المطلوب. بالطبع ، بعد انتهاء عملية الأتمتة ، تم تقديم عرض تقديمي داخلي للجميع ، حتى يكون للموظفين فكرة عن العمل المنجز ويمكنهم التعلم من الخبرة المكتسبة في هذا المشروع.
كاتب المقال: ديمتري ماسترز
ملحوظة: نحن ننشر مقالاتنا على عدة مواقع في Runet. اشترك في صفحاتنا على
VK أو
FB أو
قناة Telegram لمعرفة المزيد عن جميع منشوراتنا وأخبار Maxilect الأخرى.