Cucumber-js: لم يتم تمرير نتيجة السيناريو إلى الخطافات قبل / بعد

تعرضت للعض من هذا. تم تعليق ترقيتنا إلى 3 في Cucumber pro بسبب هذا.

هل https://github.com/cucumber/cucumber-js/blob/fbff6b0fae54d2e341ee247addc60a9f05753f1d/src/runtime/test_case_runner.js#L109 هو الجاني؟

أي جزء من هذا مطلوب بالضبط؟ هل تستخدم فقط المسندات الحالة؟ يبدو أن هذا هو الشيء الوحيد المستخدم في المستندات المحيطة بهذا

نستخدم حاليًا scenarioResult.status و scenarioResult.scenario.uri و scenarioResult.scenario.line .

jbpros هل تتبع حالة الاستخدام الأمثلة التي لدينا حاليًا حول هذا (حفظ لقطة شاشة عند فشل السيناريو)؟ لطالما اعتقدت أنه من الغريب حقًا أن يتم تمرير السيناريو في خطافات وأرغب في العثور على طريقة مختلفة للتعامل مع هذا.

حاليًا ، أعتقد أننا نضيف وظيفة رمز دعم جديدة: onFailedTestStep والتي تتيح لك تعيين وظيفة ليتم استدعاؤها مع فشل خطوة الاختبار. سيتم استدعاؤها بنفس الحجة العالمية مثل الخطوة الفاشلة ، وبالتالي يمكنك إرفاق صورة أو شيء من هذا القبيل. يمكننا إنشاء وحدة مخصصة لتحليل المرفقات من منسق بروتوكول الحدث ونسخها في مجلد.

كمستخدم tinker ، أود أن تحتوي أي وظيفة / معالج / كائن من هذا القبيل على أكبر قدر ممكن من السياق. حتى بدون وجود شيء كبير مثل شجرة التشغيل السابقة والمستقبلية بأكملها (https://github.com/cucumber/cucumber-js/issues/875) ، سيكون من المفيد للغاية معرفة الخطوة والسيناريو الحاليين كل فشل.
على سبيل المثال ، يسمح لي هذا بالتحكم في إجراءات التراجع وفقًا للعلامات ، أو مجرد رؤية الخطوات الأخرى التي تم تنفيذها قبل الخطوة الفاشلة.

أود أن أحثك ​​على التفكير في تمرير هذه إلى onFailedTestStep ، إذا كان هذا هو الحل الذي ستتبعه.

يحتاج Hook Docs إلى التحديث أيضًا - رابط الفقرة الأولى إلى ScenarioResult هو 404.

بدلاً من onFailedTestStep ، لماذا لا يتم تعريف خطاف يسمى AfterStep ؟ لقد كان Cucumber-Ruby لديه هذا لفترة طويلة وكما تعلم - الاتساق مهم.

aslakhellesoy أريد التركيز على حالة الاستخدام والتأكد من أننا

الاتساق مهم ولكن هذا لا يعني أنه يجب علينا نسخ كل شيء لمجرد وجوده في مكان آخر. يجب أن نتطور لأننا نحدد طرقًا أفضل للتعامل مع الأمور

هل يمكنك أنت أو mattwynne أو أي شخص من فريق Ruby إلقاء بعض الضوء على ما تم تصميم AfterStep من أجله ولما يتم استخدامه؟

أنا لست من فريق روبي لذلك أنا لا أعرف ما AfterStep بنيت ل، ولكن أنا شخصيا استخدام AfterStep للقيام بعمليات مختلفة. وهنا بعض الأمثلة:

1. خذ لقطة شاشة وقم بإخراج سجل المتصفح في السيناريوهات الفاشلة
2. قم بتسجيل إضافي لبعض المشاريع بغض النظر عما إذا كان قد فشل أم لا
3. نظف

بالنسبة لنا ، سنحتاج إلى تمرير السيناريو والنتيجة إلى AfterStep أي حال للقيام بتسجيل إضافي. أنا متأكد من أن هناك حالات استخدام أخرى تحتاجها في AfterStep أيضًا ، والتي لم نفكر فيها حتى.

هذا يعني أنه إذا كان هناك شيء مثل onFailedTestStep ، سيكون لدينا أكثر من طريقة لتحقيق نفس الشيء: واحدة لاستخدام AfterStep والأخرى لاستخدام onFailedTestStep .

يمكن أن يتسبب هذا في عدم الاتساق داخل المشاريع أيضًا اعتمادًا على من قام بتنفيذ الخطاف ؛ قد يستخدم البعض AfterStep بينما قد يستخدم البعض الآخر onFailedTestStep . لا أعتقد أن أيا من هؤلاء مرغوب فيه.

تضمين التغريدة

أريد أن أفهم من أين أتيت. هل تمانع في توضيح سبب اعتقادك بما يلي؟

لطالما اعتقدت أنه من الغريب حقًا أن يتم تمرير السيناريو في خطافات

لم أحب حقًا خلط النموذجين. قبل / بعد الخطافات مرتبطة بالإعداد / التفكيك مع إجراء الاختبارات فعليًا. يبدو أن استخدامه للإبلاغ أيضًا أمر يجب الاهتمام به بشكل منفصل

خذ لقطة شاشة وقم بإخراج سجل المتصفح في السيناريوهات الفاشلة

إذا كنت تفعل ذلك في AfterStep ، يتم تنفيذ ذلك للخطوات الفاشلة ، وليس السيناريوهات الفاشلة. هذا هو ما تستخدمه جميع الأمثلة الموجودة في الريبو لكائن السيناريو ولهذا السبب أريد إنشاء خطاف جديد لحالة الاستخدام المحددة هذه. لم أسمع أي حالة استخدام مقنعة أخرى.

قم بتسجيل إضافي لبعض المشاريع بغض النظر عما إذا كان قد فشل أم لا

ما هو نوع التسجيل الإضافي الذي تفعله؟

نظف

ما الذي يجب تنظيفه بعد الخطوة؟

بالنسبة لنا ، سنحتاج إلى تمرير السيناريو والنتيجة إلى AfterStep على أي حال للقيام بتسجيل إضافي. أنا متأكد من أن هناك حالات استخدام أخرى تحتاج إليها في AfterStep أيضًا ، والتي لم نفكر فيها حتى.

أحاول جمع حالات الاستخدام هذه. في بعض الأحيان قد يستخدمه الناس عندما تكون هناك طرق أخرى للقيام بذلك أو كحل بديل لشيء يمكننا بناء دعم أفضل له.

هذا يعني أنه إذا كان هناك شيء مثل onFailedTestStep ، فسيكون لدينا أكثر من طريقة لتحقيق نفس الشيء: واحدة لاستخدام AfterStep والأخرى لاستخدام onFailedTestStep.

لا يحتوي Cucumber-js حاليًا على AfterStep ولا أخطط لتطبيق كليهما.

أنا بصدد محاولة الحصول على دعم الخيار 3 في إطار عمل منقلة-خيار ويمكنني حقًا استخدام AfterStep . أدرك أن المكتبة التي تجمع مكتبتين أخريين معًا ليست أكثر حالات الاستخدام شيوعًا ، ولكنها ستجعلها أكثر بساطة. أحاول معرفة كيفية القيام بذلك مع عناصر بروتوكول الحدث الجديدة ، لكنني لا أحصل على سياق ميزة / سيناريو / خطوة في أي من أحداث *-finished . نستخدم الأسماء و uris وأرقام الأسطر من الميزة والسيناريو والخطوات لإبلاغ المنقلة وإعطاء تكامل IDE (Intellij) شيئًا لإظهاره والتنقل إليه في شجرتهم. 0.02 دولار بلدي على أي حال.

فقط لذكر أن جميع الوظائف التي تمت مناقشتها (وأكثر من ذلك بكثير) يمكن إنجازها باستخدام setDefinitionFunctionWrapper .
يمكنك التفاف جميع الخطوات بإجراءات ما قبل / بعد ، والتي لا تسمح لك فقط بالتفاعل مع مدخلات ومخرجات الخطوة ، بل حتى تقوم بتحويلها.

لذلك ، على سبيل المثال ، أستخدمه لتنفيذ خطوة "يجب أن تفشل الخطوة التالية مع الخطأ XYZ" ، والتي تتيح لي تنفيذ عمليات تحقق سلبية عميقة ومحاكاة للأخطاء بسرعة دون تنفيذ خطوات سلبية مكررة أو معالجة خاصة للأخطاء القابلة للقلب في كل خطوة. .

أعتقد أنه لا يوجد شيء يمكن لخطاف AfterStep أن يفعل ذلك setDefinitionFunctionWrapper .

أي تحديثات على هذا؟ محاولة الترقية من 2.0.0 إلى 3.0.0 في العمل ولا يزال الحصول على undefined لـ سيناريو نتيجة

@ Paul-Phillips-Ark نعم ، انظر # 905. إذا كنت ترغب في المساعدة في المضي قدمًا ، فيمكنك التفرع وإرسال رسالة علاقات عامة جديدة تتناول تعليقات

عندما أقوم console.log (سيناريو النتيجة) ما زلت أحصل على غير معرف في كل من الوظائف قبل وبعد؟ هل فاتني شيء؟ الاعتذار إذا كان التعليق أعلاه كثيفة السبر.

حالات الاستخدام الخاصة بي حاليًا هي التالية:

قبل كل سيناريو ، أطلب تركيبات تملأ قاعدة البيانات الخاصة بي للاختبار. كل ميزة لها مجموعتها الخاصة من التركيبات اللازمة لها. مسار Fixture على الخادم يكرر مسار الميزة ، لذا أحتاج إلى خيار uri أيضًا:

Before({ timeout: 60 * 1000 }, scenarioResult => {
    ...
    const file = scenarioResult.scenario.feature.uri;
    ...
});

على الخطاف After حيث يقوم الكثير منا بعمل لقطة شاشة:

After(scenarioResult => {
    if (scenarioResult.status === 'failed') {
      driverUtils.takeScreenShot(scenarioResult.scenario.name);
    }
});

charlierudolph هل يمكنك قطع الإصدار بطلب السحب # 905 كحل مؤقت؟ يسمح لنا بإنهاء الانتقال من الإصدار 2 إلى الإصدار 3 - والذي هو عالق حاليًا بسبب هذا الانحدار / التغيير. إعادة الهيكلة المقترحة الخاصة بك يمكن أن تدخل في طلب سحب آخر.

هناك بعض المشكلات الخاصة بالرقم 905 ، لكنني سأحاول الحصول على حل لها وإصدارها في نهاية هذا الأسبوع.

تم قفل سلسلة الرسائل هذه تلقائيًا نظرًا لعدم وجود أي نشاط حديث بعد إغلاقه. الرجاء فتح قضية جديدة للأخطاء ذات الصلة.