قبل أكثر من عام بقليل ، جربت أولاً إطار عمل الروبوت. خلال مشاركتي في مشروع كبير نوعًا ما ، واجهت نهجين مختلفين لاختبار الأتمتة باستخدام هذه الأداة: كتابة الاختبارات على إطار روبوت DSL خالص والعمل بالاشتراك مع Python. إذا كان المسار الأول له حد دخول منخفض ، فإن المسار الثاني ، في رأيي ، أكثر ملاءمة من وجهة نظر دعم المشاريع الكبيرة. على الرغم من عدم وجود اختلاف جوهري بين النهج. بطريقة أو بأخرى ، كل شيء يتعلق بإيجاد المكتبات.
ومع ذلك ، يجدر التحدث عن ميزات النهج.
من هو الروبوت وماذا يأكل به
ربما يستحق البدء بإدخال هذه الأداة القوية.
إطار الروبوت هو إطار للاختبار يعتمد على الكلمات الرئيسية. يتم استخدامه لأتمتة اختبار القبول و ATDD (نهج التطوير من خلال اختبار القبول). يحتوي هذا النظام على بنية بيانات اختبار سهلة الاستخدام ويسمح لك بأتمتة الاختبارات باستخدام الكلمات الرئيسية. بالإضافة إلى ذلك ، يحتوي Robot Framework على مكتبات مدمجة ممتازة وأطراف ثالثة تسمح لك ببدء الأتمتة ودمجها بسرعة في عمليات العمل دون اختراع دراجاتك الخاصة - حد الدخول المنخفض للغاية الذي ذكرته أعلاه.
يتم تنفيذ الهيكل الأساسي لـ Robot Framework باستخدام Python ويعمل أيضًا على Jython (JVM) و IronPython (.NET).
يمكن العثور على أمثلة للاستخدام ، بالإضافة إلى وثائق كاملة عن إطار العمل والمكتبات الداخلية على الموقع الرسمي للمشروع:
http://robotframework.org/ .
خطواتي الأولى. النهج الأول
لأول مرة ، صادفت إطار عمل الروبوت قبل عام ، بعد تغيير عملي. قبل ذلك ، كنت قد أتممت فقط في Java و C #.
اخترت لنفسي الأدوات التي يجب أن أتعامل معها في الاختبارات الحالية ، قابلت زملاء جدد حول تفضيلاتهم. لم يتفقوا على أفضل بيئة تطوير متكاملة للعمل مع إطار الروبوت. تسمح المكونات الإضافية لمختلف محرري النصوص و IDEs ، مثل PyCharm ، بشكل أساسي بالعمل مع Robot Framework. وتم تقسيم التوصيات التي جمعتها بنسبة 50/50 بين Atom و PyCharm. بالطبع ، هناك ركوب ، ولكن هذا ليس حلا سحريا. في ذلك الوقت (قبل عام) ، لم أجد وثائق عادية حولها ، وفي تلك التي وجدتها ، لم أر أي إيجابيات كبيرة لمهمتي. لذلك ، بالنسبة للمبتدئين ، قررت تجربة Atom مع المكونات الإضافية. عند استنساخ المستودع ، بدأت أدرس ببطء ما كان يحدث في اختباراتنا وفي إطار الروبوت نفسه.
لقد تم ربطني بالمشروع لكل شيء عمليًا. حفنة من Jython + Robot Framework عملت بالفعل هناك ، تم تجميع قاعدة شفرة ضخمة (مكتوبة على DSL Robot Framework نفسها) من أكثر من 1000 اختبار وعدة آلاف من أسطر المكتبات المساعدة في Java.
كما أفهمها ، عندما بدأ المشروع ، أي حتى قبل مجيئي إلى القسم ، كان متخصصو جافا هم الذين عملوا عليه بشكل رئيسي ، وكان المنتج قيد الاختبار نفسه في جافا ، لذلك عند اختيار نهج ، ركزنا على الموارد المتاحة. بشكل عام ، كان الحساب شيئًا من هذا القبيل: بعد حل بعض المشاكل المتعلقة بدمج إطار عمل الروبوت وجافا (ويرجع ذلك أساسًا إلى حقيقة أن لغة جافا هي لغة مجمعة ، ولكن يتم تفسير نفس Python والاختبارات في حزمة Python + RF) ، ثم من السهل جذب خبراء من أطراف ثالثة يعرفون فقط إطار عمل DSL Robot Framework ، ويكتبون الاختبارات بهدوء على الكلمات الرئيسية. صحيح ، كان على الزملاء بذل الكثير من الجهد في إنشاء مكتبات في Java ، وبالتالي ، بدون شروط من العميل ، لن يوصوا بمثل هذا المسار.
بعد أن قمت ببعض إعادة الهيكلة قليلاً ، كجزء من مهمتي الأولى ، أجريت الاختبارات أولاً. منذ استخدام حزمة Jython + RF ، تم جمع كل شيء بواسطة مخضرم ، وتم نسخ ملفات الروبوت ببساطة إلى الدليل الهدف للتنفيذ لاحقًا.
تم تشغيل الاختبارات بواسطة برامج نصية (ملفات .bat أو .sh) أخذت المسار إما إلى حالة اختبار منفصلة (ملف. robot منفصل) أو خطة اختبار (ملف يحتوي على قائمة بالمسارات النسبية لحالات الاختبار).
أثرت إعادة الهيكلة على عدد كبير من الاختبارات ، لذلك استغرق التشغيل الأول حوالي 15 دقيقة. بعد الانتهاء ، حان الوقت لإلقاء نظرة على التقارير التي يقدمها إطار عمل الروبوت.
يتكون التقرير القياسي (في لقطة الشاشة أعلاه) من ملفات report.html و log.html:
- يحتوي التقرير على ملخص عام للتشغيل السابق ، حيث يمكنك مشاهدة النتائج السطحية لجميع الاختبارات (ناجح أو فاشل) ؛
- في ملف السجل ، يمكنك رؤية معلومات أكثر تفصيلاً - تنفيذ كل اختبار خطوة بخطوة. هناك يمكنك عرض كل ما تحتاجه لتصحيح الاختبارات.
بصراحة ، من النظرة الأولى على تقرير إطار عمل الروبوت ، تبدأ العين في الارتعاش قليلاً: يتم عرض كمية كبيرة من المعلومات ويستغرق بعض الوقت لفهم هيكل الاختبارات الشامل وتطوير المهارات لقراءة مثل هذا السجل. لكن هذه الأعمال ليست صعبة للغاية. في غضون شهرين ، يمكنني أن أقتبس عن المصفوفة: "دماغك يقوم بالترجمة نفسها. أنا لا أرى الرمز حتى. أرى أشقر ، امرأة سمراء وأحمر شعر ". لذلك - رأيت جميع المعلومات الضرورية في ملف بدون أدوات إضافية.
زائد هو أنه يمكن التحكم في الإخراج: هناك مستويات مختلفة من التسجيل التي تحدد المعلومات التي سيتم عرضها وأيها لا. يمكن تعديل المستوى حتى لكل سطر على حدة من خلال طريقة المكتبة المدمجة. في الوقت نفسه ، فإن معرفة ترتيب إجراء المكالمات داخل الاختبار والمكتبات المساعدة ليس أمرًا غير ضروري - فمن الأسهل التقاط لحظة الخطأ.
باستخدام DSL Robot Framework كأداة رئيسية لدينا ، عملنا لمدة ستة أشهر تقريبًا. خلال هذا الوقت ، تحولت من التفضيلات الشخصية من Atom إلى VSCode ، لكن هذا لم يغير جوهر النهج.
ومع ذلك ، كان المشروع يتطور. في التكرار النهائي ، بلغ إجمالي المكتبة المساعدة للعمل مع قاعدة البيانات 6،700 سطر من التعليمات البرمجية في إطار Robot Framework خالص. مع هذا الحجم من قاعدة الرمز ، أصبح من الصعب الحفاظ عليه - إعادة هيكلة الموارد المطلوبة التي لم يتم تخصيصها.
تنتمي الكلمة الأخيرة في تطبيق النهج الأول إلى الأعمال. عمل عميل مشروعنا أيضًا مع فرق أخرى في المهام ذات الصلة. في أحد المسارات المتوازية ، رأى ، من وجهة نظره ، خيارًا أكثر فاعلية وتوضيحيًا لاستخدام إطار الروبوت ، والذي تم البدء في تنفيذه خصيصًا للإدارة.
النهج الثاني
النهج الثاني كان تطوير الاختبارات في Python بالاشتراك مع Robot Framework. بدلاً من إنشاء كل شيء على بناء جملة DSL Robot Framework ، بدأنا في كتابة مكتبات مساعدة وتفاعلات أخرى منخفضة المستوى مع منتج الاختبار في Python. وأصبح إطار الروبوت ، في الواقع ، مجرد عداء.
نظرًا لأن Python هي لغة نقية عالية المستوى ، وليست DSL ، فهناك المزيد من خيارات الهيكلة ، فمن الأسهل اكتشافها بالكامل. كحد أدنى ، يمكنك استخدام Python IDE لمساعدتك في العثور على نفس الأساليب (وهي تفعل نفس الشيء ، ولكن يتم تسميتها بشكل مختلف) أو حتى كتابة جزء من التعليمات البرمجية لك. يمكن لف بعض البيانات في المولدات ، وتعليق الديكور على الوظائف ، إلخ. على هذه الخلفية ، تبدو أدوات النهج الأول (إطار الروبوت النقي) قاسية إلى حد ما - في الواقع ، كانت المفكرة مع تسليط الضوء على بناء الجملة. لا مستوطنين أو رسائل يكتبها IntelliJ لك. لذلك كنت سعيدًا بالعودة إلى لغة ذات مستوى أعلى. العمل مع هذا النهج أشبه بالتطور الطبيعي. صحيح ، هناك ذبابة في المرهم. بدون رقصة إضافية ، من المستحيل فهم ما وقع داخل Python ، ودعا من RF.
ببطء ، بدأت كتابة الاختبارات الأولى والمكتبات المساعدة لنظامنا الفرعي. خلال الوقت الذي تمكنت فيه من العمل بنهج جديد ، شعرت أنه مع أداة أخرى هناك بالفعل المزيد من الفرص. ولكن في الواقع ، لم تتغير كتابة الاختبارات كثيرًا. في هذا المشروع بالذات ، داخل كود Python ، لا تزال طرق مكتبة Robot Framework المدمجة تسمى. كان هذا بسبب المتطلبات الخاصة للعميل لتطوير الاختبارات. قمنا ببساطة بفصل الجزء القابل للتنفيذ من خوارزمية حالة الاختبار.
أيهما أفضل؟
أنا شخصياً أحب النهج الثاني. ومع ذلك ، عند اختيار مسار مشروعك ، يجدر البدء من المهمة - من يكتب الاختبارات وكيف.
كما قلت أعلاه ، يوفر Python (النهج الثاني) المزيد من الفرص ، ولكن في هذه الحالة ، هناك حاجة إلى أشخاص على دراية بهذه اللغة في المشروع. إطار الروبوت نفسه (والأسلوب الأول) أقل تطلبًا - يمكنك الاقتراب منه من خلال قراءة الوثائق الرسمية على DSL الخاص به. بعد دراسة دليل المستخدم ، يمكنك إنشاء أي اختبارات - ستبدو نظيفة جدًا.
ونتيجة لذلك ، فإن Robot Framework وطريقة استخدامه في البداية أكثر ملاءمة للمختبرين اليدويين أمس دون أي خبرة برمجة صريحة بلغات عالية المستوى. حتى الشخص غير المشارك في البرمجة يمكنه كتابة اختبار ببساطة عن طريق استدعاء الكلمات الأساسية الضرورية.
ومع ذلك ، إذا كنت ترغب في إبقاء الجزء القابل للتنفيذ منفصلاً ، باتباع مثال مشروعنا ، وفي نفس الوقت إعادة صياغة الرمز في IDEs الصديقة ، فإن الطريقة الثانية هي لك.
كاتب المقال: ديمتري ماسترز
ملاحظة: ننشر مقالاتنا على العديد من مواقع Runet. اشترك في صفحاتنا على
VK أو
FB أو
قناة Telegram لمعرفة المزيد عن جميع منشوراتنا وأخبار Maxilect الأخرى.