Cucumber-js: قبل / بعد ميزة الخطاف والقرصنة

لن يتم الاتصال بـ "بعد" عندما يكون للميزات المتتالية نفس العلامة.

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

لن يتم الاتصال بعد إذا كانت الميزة التي تم وضع علامة عليها هي الاختبار الأخير في الإنشاء.

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

كما أنك تحاول إنشاء سيناريوهات متصلة وهو أمر محبط. أود أن أقترح واحدًا مما يلي:

• افصل السيناريوهات
• قم بتنفيذ cucumber-js عدة مرات بتحميل ملفات دعم مختلفة واستخدم BeforeAll / AfterAll

للتوضيح ، الحل البديل الذي أشير إليه هو:

this.Before({ tags: ['<strong i="6">@featurehook</strong>'] }, function () {
  // log user in (if needed)
})

this.Before({ tags: ['~<strong i="7">@featurehook</strong>'] }, function () {
  // log user out (if needed)
})

ضع في اعتبارك بعض الميزات:

<strong i="11">@featurehook</strong>
Feature: feature 1
   Scenario: scenario 1

<strong i="12">@featurehook</strong>
Feature: feature 2
   Scenario: scenario 2

Feature: feature 3
   Scenario: scenario 3

<strong i="13">@featurehook</strong>
Feature: feature 4
   Scenario: scenario 4

إذا تم تشغيلهما بالترتيب أعلاه ، فلن يحدث التمزيق بين الميزة 1 والميزة 2. لن يحدث التمزيق بعد الميزة 4 إما لأنه لن يكون هناك اختبار آخر مطابق ~ @ featurehook (من المسلم به أنه يمكن إصلاح ذلك باستخدام بعد كل ذلك).

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

خذ مثالاً على اختبار يقوم بإعداد خادم SMTP تجريبي بتكوينات مختلفة:

<strong i="20">@smtpConfig1</strong>
Feature: ....

<strong i="21">@smtpConfig2</strong>
Feature: ....

قد تكون هناك آثار جانبية بين السيناريوهات من خلال عدم تمزيقها ، لكن المفاضلة بين النقاء والأداء قد تستحق العناء في هذه الحالة.

آسف ولكن هذا ليس شيئًا أعتقد أنه يجب دعمه. هناك القدرة على مشاركة الحالة عبر جميع السيناريوهات وعبر سيناريو واحد يغطي الغالبية العظمى من الحالات. لم يتم حل المثال الخاص بك في التعليق الأخير (معfeaturehook) من خلال وجود BeforeFeature / AfterFeature على أي حال.

+1 لخطافات قبل الميزة / بعد الميزة
أوافق على الحاجة إلى تحقيق التوازن بين الأداء وعزل الاختبار. الطريقة التي تم بها بناء إطار العمل في الوقت الحالي ، هناك القليل جدًا الذي يربط السيناريوهات في ميزة واحدة ، باستثناء خطوات الخلفية التي يتم تكرارها. في بعض الحالات ، قد لا نرغب في تكرار خطوات الخلفية ، ولكن بدلاً من ذلك ، يجب أن تحدث مرة واحدة في بداية الميزة ، ويتم تفكيكها بمجرد اكتمال جميع السيناريوهات.

نظرًا لأنني أستخدم خدمة مثل Browserstack ، وهي خدمة بطيئة ومؤلمة دائمًا للعمل معها (وكذلك مزودي الخوادم الآخرين عن بُعد مثل Saucelabs) ، فأنا عادةً ما أستخدم معالجات أحداث BeforeFeature و AfterFeature لإعداد جلسات السيلينيوم وتفكيك كل ملف ميزة.

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

يجب اعتبار هذا كحالة لإعادة استخدام خطافات الميزات قبل / بعد لاستخدامها بدلاً من تنفيذ cucumberjs لكل ملف ميزة كما هو مقترح أعلاه.

تعتبر الخطافات BeforeFeature/AfterFeature ضرورية لاختبار e2e / uat / bdd / call-it-أيًا كان ما تريده-اختبار صنع الخيار من أجله.

يدعم "المنافسون" الرئيسيون لـ Cucumber هذا (على سبيل المثال JBehave و RobotFramework) ، وبدون أي اختراقات ؛ إنها ميزة مناسبة لإطار العمل.

هذه المشكلة هي بالتأكيد مانع لاستخدام الخيار.

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

تكمن المشكلة في أنه عندما يكون السيناريو الذي يستخدم تلك البيانات (ويطلق الخطافات) هو آخر سيناريو يتم تنفيذه ، فلن يتم تشغيل الخطاف اللاحق أبدًا ...

أي طريقة لحل هذا ؟؟

شكرا

+1 لميزة قبل وبعد.
حالة الاستخدام لدينا هي: وجدنا أخطاءً في بعض المتصفحات لا تظهر في متصفحات أخرى.

نريد وضع علامة على ميزة مثل:

@ie-8-only
Business Need: IE8 should have limited functionality, but what is displayed, should be displayed correctly

@no-access @ssl-insecurity <strong i="8">@security</strong> @BUG-1876
Scenario: No access
   Given I am on the home page
   When I see that my browser is not supported
   Then I should not be able to access the core site functionality

@formatting-issue <strong i="9">@bugs</strong> @BUG-1210
Scenario: The menu should not be formatted like a staircase
   For the users to be able to navigate to the about us / contact us area of the site, the site navigation should be active
   Given I am on the home page
   When I see the menu
   Then it should be displayed in a line

سيسمح لنا هذا بإغلاق المتصفح وفتح IE في خطاف BeforeFeature ، وإعادة فتح المتصفح الذي نستخدمه لبقية المجموعة في خطاف AfterFeature. يستغرق إغلاق المتصفح وإعادة فتحه وقتًا طويلاً عندما تقوم بذلك في كل سيناريو ، مما يجعل هذه الميزة رائعة للاستخدام.

ملحوظة:
أعلم أن هناك بدائل تتضمن الكائن العالمي (إعداد المتصفح الحالي هناك ، وإغلاقه فقط إذا لم يكن المتصفح هو ما نحتاجه في السابق تم القيام به في خطاف بالفعل أو يقرر السيلينيوم أنه سيرمي نوبة هيسي نصف الوقت.

هناك أوقات أخرى قد ترغب فيها في إرفاق نص بالميزة كوصف مضاف لها في خطاف BeforeFeature ، وهو مثال آخر على المكان الذي قد يكون فيه ذلك مفيدًا

أعتقد أيضًا أنه قبل / بعد ميزة الخطافات ستكون مفيدة في أنواع معينة من الاختبارات. على سبيل المثال ، تم تنفيذ Specflow ، مكتبة Cucumber لـ .NET ، بما يلي:
https://specflow.org/documentation/Hooks/

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