في الفترة من 6 إلى 7 ديسمبر ، تم عقد مؤتمر Heisenbag الخامس في موسكو.
شعارها هو "اختبار. ليس فقط للمختبرين! "، ولمدة عامين من الزيارات المنتظمة إلى Heisenbags ، تمكنت مني (سابقًا مطور Java ، وأصبحت الآن رائدة تقنيًا في شركة صغيرة لم تعمل مطلقًا في مجال ضمان الجودة) أن تتعلم الكثير في اختبار وتنفيذ الكثير في فريقنا. أرغب في مشاركة مراجعة ذاتية للتقارير التي أتذكرها هذه المرة.
إخلاء المسؤولية. بالطبع ، هذا ليس سوى جزء صغير (8 من 30) من التقارير المحددة بناءً على تفضيلاتي الشخصية. ترتبط جميع هذه التقارير تقريبًا بجافا ولا يوجد تقرير واحد حول تطوير الواجهة الأمامية والجوّال. في بعض الأماكن ، سأسمح لنفسي بجدل مع المتكلم. إذا كنت مهتمًا بمراجعة أكثر اكتمالا ومحايدة ، فيجب أن تظهر
في مدونة المنظمين . ولكن ، ربما سيكون من المثير للاهتمام أن يكتشف شخص ما تلك التقارير التي لم يتمكنوا من الذهاب إليها.
الصور في المقال هي من تويتر الرسمي للمؤتمر.باروخ سادوجورسكي. لدينا DevOps. دعنا نطلق جميع المختبرين
(في الصورة - الضجيج عندما قام باروخ بتوزيع كتاب Liquid Software )المشاركون في Java وحضور مؤتمرات مجموعة JUGRU ، Baruch Sadogursky لا يحتاج إلى مقدمة. ومع ذلك ، قام بأداء لأول مرة في Heisenbug.
باختصار - لقد كان تقرير مراجعة حول الأفكار الرئيسية لـ DevOps. تبقى حاجة الجمهور إلى مثل هذه التقارير ، لأنه عندما يُسأل "أعط تعريف DevOps" للجمهور ، لا يزال الناس يجيبون أولاً "هذا هو مثل هذا الشخص ..."
ولكن حتى أولئك الذين تعلموا بالفعل شيئًا ما حول هذا الموضوع ، سيكون من المثير للاهتمام للغاية معرفة دراسات جمعية DORA
devops-research.com ، التي حصلت على نسب مئوية من أنواع العمل اليدوي في فرق ذات أداء مختلف. وحول المنحنى الذي يربط سرعة التسليم وجودته (في مرحلة ما ، تقل السرعة ، لأننا نحتاج إلى وقت لإجراء "اختبار أفضل" ، ولكن مع تطور الفريق ، يصبح الارتباط مباشرًا):
على الرغم من أن عنوان التقرير كان استفزازيًا ، وفي الجدول تم وضع علامة على التقرير تحت عنوان "سوف يحترق" ، إلا أن محتواه كان ، في رأيي ، التيار الرئيسي. بالطبع ، لم يكن الأمر يتعلق بفصل المختبرين في ظل ظروف تحول Devops ، وإنما يتعلق بتغيير في طبيعة عمل المختبرين.
تحدث آلان بيج ونيكولاي أليمنكوف كثيرًا عن هذه الأشياء قبل عام. نوقشت كل من الأدوار المتغيرة والتطوير "الأفقي" للمهارات على شكل حرف T منذ عام في المائدة المستديرة "
ما يجب أن يعرفه المختبر في عام 2018 "
"بالطبع ، إذا كنت لا تريد التغيير ، فهناك عمل لك ، وإن لم يكن مثيرًا للاهتمام. حتى الآن ، لا يزال هناك عمل لأولئك الذين يرغبون في دعم الأنظمة المكتوبة في كوبول في السبعينيات.
أرتيوم إروشينكو. تحتاج إلى refactor مشروع؟ لديك فكرة!
Artyom مألوف للمشاركين في Heisenbag بتقارير عن نظام الإبلاغ Allure (على سبيل المثال ،
هنا تقريره عن فرص Allure الذي ظهر في عام 2018 من Heisenbag السابق في St. ولد Allure نفسه في سياق المشاريع مع الآلاف ، وعشرات الآلاف وحتى أكثر من مئات الآلاف من الاختبارات ، وهو مصمم لتبسيط التفاعل بين المطورين والمختبرين. لديه القدرة على ربط الاختبارات مع الموارد الخارجية مثل أنظمة التذاكر والالتزامات في نظام التحكم في الإصدار. في فريقنا الصغير ، بينما كان عدد الاختبارات يمر بعشرات فقط ، تعاملنا تمامًا مع الوسائل القياسية. ولكن نظرًا لأن عدد الاختبارات في أحد المنتجات بلغ 700 اختبار وكانت المهمة الإجمالية هي إنشاء تقارير عالية الجودة للعملاء ، فقد بدأت أتطلع إلى Allure.
ومع ذلك ، لم يكن هذا التقرير حول جاذبية ، على الرغم من أنه أيضا.
أقنع آرتيوم الجمهور بأن كتابة الإضافات لـ IntelliJ IDEA هو نشاط بسيط ورائع. لماذا هذا مطلوب؟ لأتمتة تعديل التعليمات البرمجية السائبة. على سبيل المثال ، لترجمة عدد كبير من أكواد المصدر من JUnit4 إلى JUnit5. أو من استخدام Allure 1 إلى Allure 2. أو لأتمتة علامات الاختبارات مع التواصل مع نظام التأشير.
أولئك الذين يعملون مع IDEA يعرفون الحيل التي يمكن أن يفعلوها بالشفرة (على سبيل المثال ، ترجمة الشفرة تلقائيًا باستخدام الحلقات إلى رمز باستخدام Java Streams والعكس بالعكس ، أو ترجمة Java على الفور إلى Kotlin). الأكثر إثارة للاهتمام هو النظر في كيفية فتح حجاب السرية على تحويلات الكود في IDEA ، فنحن مدعوون للمشاركة في هذا ، وإنشاء ملحقاتنا الخاصة لتلبية احتياجاتنا الفريدة. في المرة القادمة ، عندما أحتاج إلى القيام بشيء ما باستخدام قاعدة كبيرة من التعليمات البرمجية ، سأتذكر هذا التقرير وأرى كيف يمكن تشغيله تلقائيًا باستخدام مكون إضافي عام في IDEA.
كيريل مركوشيف. مشروع جافا ومفاعل - ماذا عن الاختبارات؟
يبدو لي أن هذا التقرير قد حدث في مؤتمرات Joker أو JPoint Java. تحدث كيريل عن كيفية استخدامه
لإطار عمل
projectreactor.io في بنية الخدمات المصغرة مع سجل أحداث واحد (Kafka) ، قليلاً عن جوهر الترميز على "التدفقات التفاعلية" ، بما في ذلك كيف يمكن تصحيح أخطاء التطبيقات التي تستخدم هذا الإطار واختبارها.
الحياة تدفع أيضًا فريقنا لاستخدام الهندسة المعمارية مع سجل أحداث واحد ، وننظر أيضًا إلى كافكا. صحيح ، بالنسبة إلى أحداث البث المباشر ، فإننا نجرب على تطبيق واجهة برمجة تطبيقات Kafka Streams (حيث يبدو لي أن هناك المزيد من الأشياء مثل المعالجة الفعالة يتم تنفيذها من خارج الصندوق بشفافية للمطور) وليس Reactor. ومع ذلك ، كما هو الحال دائمًا مع التقنيات الجديدة ، فإن "أشعل النار" و "المزالق" غير معروفة مسبقًا. لذلك ، كان من المهم الاستماع إلى قصة أخصائي يعمل بالفعل مع التكنولوجيا.
ليونيد رودنكو. إدارة سيلينويد العنقودية مع Terraform
إذا كان التقرير السابق يذكرنا بمؤتمر JPoint ، فهذا بالتأكيد يتعلق بـ
DevOops . تحدث ليونيد حول كيفية استخدام مواصفات Terraform لرفع وتكوين كتلة سيلينويد. حول ما كان Selenoid نفسه ، كان هناك
تقرير عن Heisenbug العام الماضي - إنه نظام موزع غني يعمل كخدمة مرنة ويسمح لك بإجراء عدد كبير من اختبارات السيلينيوم في مختلف المتصفحات. مثل أي نظام يتطلب النشر على العديد من الأجهزة ، من الصعب تثبيت Selenoid يدويًا. هنا ، تأتي أنظمة التهيئة الحديثة في عملية الإنقاذ.
قدم ليونيد نظرة عامة مفصلة إلى حد ما على إمكانيات Terraform - وهو نظام ربما لم يكن مألوفًا لدى معظم الجمهور ، ولكنه بالفعل معروف جيدًا لأتمتة DevOps (على سبيل المثال ، في مؤتمر Devoops-2018 ، كان هناك
تقرير ممتاز صادر عن Anton Babenko حول أفضل الممارسات لإنشاء رمز والمحافظة عليه على Terraform). علاوة على ذلك ، تم توضيح كيفية استخدام البرامج النصية Terraform لوصف المعلمات من حاويات عامل ميناء مع Selenoid لكل من الآلات في الكتلة ومعلمات الأجهزة الظاهرية الكتلة أنفسهم.
على الرغم من أن الحالة المحددة التي نظر فيها ليونيد هي بالتأكيد قادرة على تسهيل مهمة نشر سيلينويد ، إلا أنني لا أتفق مع المتحدث حول كل شيء. بشكل أساسي ، يستخدم Terraform لمهمتين مختلفتين: إنشاء الموارد وتكوينها. وهذا يؤدي إلى حقيقة أن ليونيد مجبر على تشغيل Terraform مرة واحدة لإنشاء أجهزة افتراضية ومرة أخرى لكل من الأجهزة الافتراضية لرفع حاويات الإرساء عليها. في رأيي ، فإن Terraform ، الذي يحل مشكلة إنشاء الموارد جيدًا ، لا يحل مشكلة التكوين جيدًا. قد يكون من الممكن تجنب مضاعفة مشاريع terraform وإطلاقها المتكرر باستخدام أنظمة تهيئة خاصة ، على سبيل المثال Ansible ، أو حلول أخرى.
ولكن بشكل عام ، باعتباره "برنامجًا تعليميًا" للمختبرين في مجال البنية التحتية كقانون ، فإن هذا التقرير مفيد للغاية.
أندريه ماركيلوف. اختبار تكامل أنيق لحديقة حيوانات microservice مع TestContainers و JUnit 5 باستخدام مثال النظام الأساسي SMS العالمي
ومرة أخرى عن الخدمات الصغيرة! هذه المرة ، كان الحديث يدور حول كيفية إجراء اختبارات تتطلب تشغيل وتفاعل العديد من الخدمات في نفس الوقت. تم اقتراح JUnit5 مع
نظام الامتداد الخاص به وإطار TestContainers المعروف (والممتاز) كأساس للحل (انظر ، على سبيل المثال ،
تقرير العام الماضي من قبل سيرجي إيجوروف ).
إذا كنت تكتب شيئًا ما في Java وما زلت لا تعرف ماهية TestContainers ، فإنني أوصيك بشدة بدراسته. يسمح TestContainers ، باستخدام تقنية Docker ، مباشرة في رمز الاختبار لالتقاط قواعد البيانات الحقيقية والخدمات الأخرى ، وتوصيلها عبر الشبكة ، ونتيجة لذلك ، إجراء اختبار التكامل في البيئة التي تم إنشاؤها في وقت تم إطلاق الاختبارات وتدميرها مباشرة بعد ذلك. في الوقت نفسه ، يعمل كل شيء مباشرةً من كود Java ، ويتصل بصفته تبعية Maven ولا يتطلب تثبيت أي شيء آخر غير Docker على خادم الجهاز / CI الخاص بالمطور. لقد تم استخدام TestContainers منذ أكثر من عام الآن.
أظهر Andrey مثالًا مثيرًا للإعجاب على كيفية وصف تكوين بيئة الاختبار للاختبارات من البداية إلى النهاية باستخدام امتدادات JUnit5 والتعليقات التوضيحية المخصصة و TestContainers. على سبيل المثال ، كتابة التعليقات التوضيحية على الاختبار (رمز الشرطية)
@Billing @Messaging
يمكننا ، نسبيا ، الكتابة
@Test void systemIsDoingRightThings(BillingService b, MessagingService m) {...}
في المعلمات التي سيتم من خلالها تمرير واجهات Java والتي يمكنك من خلالها التواصل مع خدمات حقيقية مرفوعة (دون أن يلاحظها أحد مطور الاختبار) في حاويات.
هذه الأمثلة تبدو أنيقة جدا. بالنسبة لي ، كمستخدم نشط لـ TestContainers و JUnit 5 ، فهي سهلة الفهم وسهلة التنفيذ نسبيًا.
ولكن بشكل عام ، مع هذا النهج ، يبقى السؤال الكبير دون حل ، وهو يتعلق بحقيقة أن طريقة تكوين أنظمة الاختبار والإنتاج مختلفة اختلافًا جذريًا.
لا يمكن تطبيق الإصدارات السريعة في الإنتاج دون خوف من كسر كل شيء إلا إذا لم يكن النظام بأكمله قد تم اختباره فحسب ، ولكن أيضًا طريقة تكوينه أثناء الاختبار الشامل. إذا قمنا بتشغيل البرنامج النصي لنشر النظام بشكل متكرر أثناء عملية التطوير والاختبار ، فلن يكون لدينا شك في أن هذا البرنامج النصي سوف يعمل حتى عند إطلاقه في الإنتاج. يتم تنفيذ دور الكود الذي يقوم بتكوين بيئة الاختبار في مثال Andrey بواسطة التعليقات التوضيحية. لكن في الإنتاج ، نضع النظام باستخدام كود مختلف تمامًا - Ansible ، Kubernetes ، أي شيء - لا يشارك بأي طريقة مع اختبار النظام هذا. وهذا يحد من هذه الاختبارات ، والتي ليست تماما نهاية إلى نهاية.
أندريه جلازكوف. أنظمة الاختبار مع التبعيات الخارجية: المشاكل ، والحلول ، Mountebank
بالنسبة لأولئك الذين يعتبر موضوع هذا التقرير ملائمًا لهم ، أوصي بشدة بمشاهدة
عرض تقديمي مشرق قدمه Andrei Solntsev حول طريقة مبدئية لاختبار الأنظمة التي تعتمد على الخدمات الخارجية. يتحدث Solntsev بشكل مقنع عن الحاجة إلى استخدام mocks النظام الخارجي لاختبار شامل. ويصف Andrei Glazkov في تقريره أحد الأنظمة لمثل هذا التبول - Mountebank ، المكتوب في NodeJS.
يمكنك رفع Mountebank كخادم و "تدريب" الإجابات على الطلبات عبر الشبكة بطريقة تشبه الطريقة التي "ندرب" بها يتهكم واجهة عند كتابة اختبارات وحدة. الفرق الوحيد هو أنها وهمية من خدمة الشبكة. إحدى الحالات الغريبة لاستخدام Mountebank هي القدرة على استخدامه كبديل - إرسال بعض الطلبات إلى نظام خارجي حقيقي.
تجدر الإشارة هنا إلى أنني أوصي بأن مطوري Java (ووافقت Andrei في منطقة المناقشة) على مكتبة WireMock ، التي يتم إنشاؤها في Java ويمكن تشغيلها في وضع مضمن ، أي مباشرةً من الاختبارات دون تثبيت أي إما خدمات لجهاز المطور أو خادم CI (على الرغم من أنه يمكن أن يعمل أيضًا كخادم مستقل). مثل Mountebank ، يدعم WireMock وضع الوكيل. لدينا بعض التجارب الإيجابية مع WireMock.
ومع ذلك ، تتمثل ميزة Mountebank في دعم البروتوكولات ذات المستوى الأدنى (يعمل WireMock فقط من أجل HTTP) والقدرة على العمل في "حديقة حيوان" من التقنيات المختلفة (توجد مكتبات بلغات مختلفة لـ Mountebank).
كيريل تولاتشيف. اختبار والبكاء مع اختبار التمهيد الربيع
ومرة أخرى Java و microservices و JUnit 5. تعد Kirill متحدثًا آخر لمؤتمرات Joker و JPoint ، المعروفة لمجتمع Java ، الذي تحدث لأول مرة في Heisenbug.
هذا التقرير هو نسخة معدلة من تقرير
Spring Curse للعام الماضي ، مع أمثلة معدلة لـ JUnit5 و Spring Boot 2. يتم فحص المشكلات العملية المختلفة المتعلقة بتكوين اختبارات Spring Boot في اختبارات المكون / الخدمة المجهرية بعمق. على سبيل المثال ، أعجبت بمثال استخدام
@SpringBootConfiguration StopConfiguration في المكان الصحيح في شجرة المصدر لإيقاف عملية المسح الضوئي للتكوين ، وكذلك إمكانية استخدام
@MockBean و
@SpyBean بدلاً من mocks. مثل تقارير أخرى من Cyril و Evgeny Borisov ، هذه مادة تجعل من المنطقي العودة إليها في عملية الاستخدام العملي لإطار Spring Spring.
أندريه كاربوف. ما الذي يمكن للمحللين الاستاتيكيين فعله ، وما لا يستطيع المبرمجون والفاحصون القيام به
تحليل كود ثابت هو شيء جيد. وفقًا لشرائع التسليم المستمر ، يجب أن تكون هذه هي المرحلة الأولى من خط أنابيب التسليم ، حيث تقوم بتصفية الشفرة مع المشكلات التي يمكن اكتشافها عن طريق "قراءة" الرمز. يعد التحليل الثابت جيدًا لأنه سريع (أسرع بكثير من الاختبارات) ورخيص (لا يتطلب بذل جهود إضافية من الفريق في شكل اختبارات كتابية: لقد تمت كتابة جميع الاختبارات بالفعل بواسطة مؤلفي المحلل).
قام Andrey Karpov ، أحد مؤسسي مشروع PVS-Studio (المعروف لدى قراء Habr بمدونته) ، بإنشاء تقرير حول أمثلة عن الأخطاء الموجودة في تحليل الكود الخاص بالمنتجات المعروفة التي تم العثور عليها باستخدام PVS-Studio. يعد PVS Studio نفسه منتجًا متعدد اللغات ، وهو يدعم C و C ++ و C # ومؤخرًا Java.
على الرغم من أن الأمثلة المذكورة أعلاه كانت مثيرة للاهتمام وفائدة التحليل الثابت لها واضحة ، في رأيي ، فإن تقرير أندريه كان به عيوب.
أولاً ، تم تصميم التقرير فقط عند النظر في منتج PVS-Studio (والذي ، وفقًا للمتحدث ، "يبلغ متوسط سعر البطاقة 10000 دولار"). ولكن تجدر الإشارة إلى أنه ، في الواقع ، يوجد في العديد من اللغات العديد من أنظمة التحليل الثابت مفتوحة المصدر. في Java لوحدها - حققت Checkstyle و SpotBugs المجانية (الخلف لمشروع FindBugs المجمد) ، بالإضافة إلى محلل IntelliJ IDEA ، والذي يمكن إطلاقه بشكل منفصل عن IDE وتلقي تقرير ، تقدماً هائلاً.
ثانياً ، عند الحديث عن التحليل الثابت ، يبدو لي أنه من الجدير بالذكر أن نذكر القيود الأساسية لهذه الطريقة. لم يطلع الجميع على نظرية الخوارزميات في الجامعة وعلى دراية "مشكلة الاغلاق" ، على سبيل المثال.
وأخيرًا ، لم تثر مشكلات إدخال التحليل الثابت في قاعدة الشفرة الحالية على الإطلاق ، ما زال يمنع الكثير من الاستخدام المنتظم للمحللات في المشروعات. على سبيل المثال ، أدارنا المحلل في مشروع قديم كبير ووجدنا 100،500 Vorings. لا يوجد وقت وجهد لإصلاحها في الحال ، وتغيير شيء ما في الكود يمثل مخاطرة كبيرة. ماذا تفعل مع هذا ، كيف نجعل التحليل الثابت يعمل كبوابة للجودة؟ تمت مناقشة هذه المشكلة في منطقة المناقشة مع Andrei ، لكن لم يتم بحث هذه المشكلة في التقرير نفسه.
بشكل عام ، أتمنى لأندري وفريقه كل النجاح. منتجهم مثير للاهتمام وفكرة احتلال مكانته في هذا المجال جريئة للغاية.
***
ربما لن أقول أي شيء عن الكلمات الأساسية النهائية في اليومين الأول والثاني: لقد كان كلاهما دليلًا لحقوق الطبع والنشر تحتاج فقط إلى مشاهدته. الحديث عنها يشبه إعادة سرد الكلمات ، على سبيل المثال ، أداء فرقة موسيقى الروك.
في تقريري
قبل عام ، حاولت بالفعل أن أنقل الجو العام للمؤتمر وتحدثت عما يحدث في مجالات المناقشة ، في الغداء وفي الحفلة ، لذلك لن أكرر نفسي.
في الختام ، أود أن أشكر المنظمين على مؤتمر آخر عقد بشكل جميل. كما أفهمها ، فإن الاهتمام بالمؤتمر فاق التوقعات قليلاً ، كان هناك بعض التحفظات وليس لدى الجميع هدايا تذكارية كافية. ولكن بالتأكيد ، كان لدى الجميع أشياء أكثر أهمية: تقارير شيقة ، مساحة نقاش ، طعام ومشروبات. إنني أتطلع إلى اجتماعات جديدة!