Cucumber-js: النتيجة مفقودة السيناريو والعلامات

لا. لا يمكنك الوصول بسهولة إلى علامات حالة الاختبار. لا توجد خطة للعودة إلى نتيجة السيناريو القديم. ما هي حالة استخدامك للحاجة إلى العلامات؟

في حالتي لدي الاعتماد على نظام العلامات. من أجل الحصول على بعض البيانات في الخطافات اللاحقة.

شيء من هذا القبيل:

<strong i="7">@SuiteName</strong> <strong i="8">@SuiteSectionName</strong> <- These tags tell the suite
Feature: 

<strong i="9">@TC1563697</strong> <- This tag identifies the testcase in the test management tool <strong i="10">@New</strong>
Scenario: 
    Given  
    When 
    Then 

يمكنك إنشاء خطافات تعمل فقط للسيناريوهات ذات العلامات المحددة: https://github.com/cucumber/cucumber-js/blob/v3.0.1/docs/support_files/hooks.md#tagged -hooks

لدي أيضًا العديد من حالات الاستخدام لمعرفة علامات السيناريو. بالنظر إلى مثال sudo التالي (فقد بناء جملة الإصدار قليلاً لأن لدي حالات اختبار في 1.3.1 ، وأنا أنظر إلى الإصدار 3.0.1 الأحدث):

<strong i="6">@set_video</strong> <strong i="7">@youtube</strong>
Scenario: User should see youtube video

<strong i="8">@set_video</strong> <strong i="9">@vimeo</strong>
Scenario: User should see vimeo video


this.After({tags: @set_video}, function (testCase) {
  let tags = testCase.scenario.tags;

_.forEach(tags, (function (tag) {
 if(tag === '<strong i="10">@youtube</strong>') {
   setVideo('youtube');
 }
if(tag === '<strong i="11">@vimeo</strong>') {
 setVideo('vimeo');
}
});

}

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

هل يمكنني أيضًا أن أسأل هنا لا يمكنني الحصول على الكائن الناتج في خطاف بعد في 3.0.1. لقد جربت testCase و سيناريو النتيجة و السيناريو. هل فاتني شيء؟

لدينا حالة نحتفظ فيها بحالات الاختبار الخاصة بنا في TestRail ونقوم بتنزيلها وحفظها كملفات ميزات قبل التشغيل.

ثم في الخطاف اللاحق ، نرسل نتائج اختبار مفصلة إلى قاعدة بيانات SQL الخاصة بنا. هذه النتائج تشمل:

• معرف الميزة من TestRail - مأخوذ من علامة (كل ميزة قامت تلقائيًا بإنشاء علامة مع معرف الميزة)
• الاستثناء الذي تم طرحه - مأخوذ من scenario.getException() في الخيار 1.x
• جميع العلامات المميزة بالميزة
• الخطوات التي فشلت - نستخدم الخطاف stepResult للحصول على نتيجة كل خطوة
• مجموعة من المعلومات الأخرى التي تم الحصول عليها من TestRail باستخدام معرف الميزة المأخوذ من العلامات

لذا مع التغيير الحالي في الخيار 3.x لن نتمكن أبدًا من التبديل لأنه يكسر بنيتنا التحتية تمامًا.

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

أنا شخصياً لدي برنامج نصي مغلف يطلق الخيار.
يقوم بتنزيل سيناريوهات TestRail قبل إطلاق الخيار ، لذلك لم تكن مشكلة كبيرة بالنسبة لي لنقل كود تقرير TestRail من خطافات الخيار إلى البرنامج النصي المجمع.
بعد اكتمال الخيار ، يقرأ البرنامج النصي ناتج CucumberResults JSON ، ويجمع كل المعلومات التي يحتاجها من هناك.

يبدو أنه سيتعين عليك إعادة ترتيب التعليمات البرمجية الخاصة بك في كلتا الحالتين.
أعتقد أن نقل جميع الإجراءات السابقة / اللاحقة إلى برنامج نصي مُغلَّف هو حل جيد يستعيد بعض عناصر التحكم التي فقدناها في V3.
لا يزال الأمر مؤلمًا إلى حد ما ، حيث يتعين علي إجراء تسلسل لمعلومات السياق المهمة لإثراء النتائج الناتجة (حيث يتم تدمير حالة البنية التحتية الخاصة بي بحلول الوقت الذي يتم فيه تشغيل الكود ذي الصلة) ، ولكن هذا ممكن.

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

yaronassa ، نجري اختباراتنا من خلال منقلة ، لا نطلق الخيار مباشرةً ، لذلك هناك طبقة أخرى من التجريد يمكن الاعتماد عليها هنا.

نقوم بتنزيل الميزات قبل أن تبدأ Protractor كما تفعل ولكن إرسال النتائج إلى قاعدة البيانات قصة مختلفة.

مع تشغيل التجزئة والاختبارات على شبكة السيلينيوم وإعادة تشغيل الميزات الفاشلة ، سيكون من المتاعب والمعقدة الحصول على النتائج بالترتيب الصحيح في قاعدة البيانات. قدر كبير من العمل لاستعادة القدرات التي كانت لدينا في الخيار 1 و 2.

كما أن إنشاء منسق مخصص فقط للحصول على نتائج خطوات لا يبدو صحيحًا.

مرحبًا ، أنا معك.
كنت أرغب في الوصول غير المقيد إلى الحالة الحالية للخيار - الميزة والسيناريو والخطوة ، مع مجموعة الخصائص بالكامل ، والوصول للكتابة (حتى أنني أرغب في الوصول إلى "مكدس المكالمات" المستقبلي للسيناريوهات ، مع القدرة على معالجته مسبقًا ).

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

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

@ gd46 يمكنك القيام بما يلي:

this.After({tags: "<strong i="7">@set_video</strong> and @youtube"}, function () {
  setVideo('youtube');
})

this.After({tags: "<strong i="8">@set_video</strong> and @vimeo"}, function () {
  setVideo('vimeo');
})

لا يحتوي هذا على أي تكرار بخلاف علامة @set_video .

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

ثم في الخطاف اللاحق ، نرسل نتائج اختبار مفصلة إلى قاعدة بيانات SQL الخاصة بنا.

هل تحتاج إلى القيام بذلك في ربط After ؟ هل يمكنك القيام بذلك بعد انتهاء الاختبارات بتحليل نتائج منسق json؟ يمكنك استخدام مُنسق بروتوكول الحدث للاستمرار في ذلك عند حدوث النتائج على الرغم من أن ذلك يتطلب مزيدًا من المعالجة. أحد منتجات التغييرات 3.x هو أن نتائج التحليل تنتقل من ملفات الدعم إلى العمليات المستقلة. أعتقد أن هذا فصل أفضل للأشياء ومن الناحية المثالية كيف بُنيت الأشياء في الأصل.

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

يمكنك إضافة لقطات شاشة باستخدام الوظيفة attach لإخراجها في حالة تنسيق potocol / json ثم القيام ببعض المعالجة اللاحقة لحفظها في الملفات بناءً على اسم السيناريو. ليس جانبًا: لا يمكن ضمان أن يكون اسم السيناريو فريدًا بينما يكون عنوان URL الخاص بالسيناريو ورقم السطر.

charlierudolph أفترض أن هذا حل بديل قوي لاحتياجاتي. كما أنه يزيل الحاجة إلى تحليل سيناريو التشغيل الحالي. قد يؤدي ذلك فقط إلى تحديد عدة مجموعات من الخطافات التي تمثل التركيبات المختلفة التي يمكن أن تتعامل معها وظيفة معينة داخل خطاف.

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

أحد الأمثلة على ذلك:

tags: <strong i="9">@clear_w2OnlyUser</strong>, <strong i="10">@clear_w2OnlyArcotEnableUser</strong>

I split based on <strong i="11">@clear_</strong> and grab the second half as the parameter. tagName coming from the old scenario result of getTags, getName. 

let profileToClear = tagName.split('<strong i="12">@clear_</strong>')[1];

browser.waitForAngularEnabled(false);
browser.get(url);
login();
navigate();
deleteProfile(profileToClear);

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

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

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

أنا أستخدم Cucumber-js لقيادة السيلينيوم. كلا المحلي و Browserstack

كنت أستخدم حالة الاختبار (الميزة ، السيناريو ، العلامات ، النتائج ، إلخ) في الخطافات للعديد من الأشياء الأساسية.

• لإجراء تعديلات خاصة بالسيناريو على عنوان URL
• ديناميكيًا تخطي الاختبارات بناءً على تكوين المتصفح الحالي
• استخدم عنوان URL الخاص بالسيناريو لتسجيل نتائج الاختبار مرة أخرى في Browserstack
• استخدم أسماء الميزات والسيناريوهات لإنشاء أسماء الجلسات في Browserstack
• تحليل العلامات لتحديد وتعيين دقة المستعرض الخاصة بالسيناريو

تم تغليف كل هذه التطبيقات في التطبيقات لتمكين المثيلات المتزامنة لتقليل وقت التشغيل الإجمالي.

لماذا تم إسقاط هذه؟
هل هم لن يعودوا ابدا؟

@ gd46

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

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

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

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

يمكنك تسجيل سطر السيناريو و uri (وهو أمر فريد بالفعل ويمنعك من البحث عن اسم السيناريو).

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

لإجراء تعديلات خاصة بالسيناريو على عنوان URL

يمكنك استخدام خطوة لهذا بدلاً من ذلك أو استخدام علامات فريدة

ديناميكيًا تخطي الاختبارات بناءً على تكوين المتصفح الحالي

كيف كنت تتخطى بشكل ديناميكي الاختبارات؟ # 912 يضيف دعمًا لهذا

استخدم عنوان URL الخاص بالسيناريو لتسجيل نتائج الاختبار مرة أخرى في Browserstack

يمكنك استخدام الخط و uri بدلاً من الاسم. كما لوحظ من قبل ، فإن السطر و uri مضمونان فريدان بينما الاسم ليس كذلك. أقترح أيضًا تحليل مُنسق json أو مُنسق بروتوكول الأحداث لنتائج الاختبار واستخدام المرفقات إذا كنت بحاجة إلى إضافة أي شيء.

استخدم أسماء الميزات والسيناريوهات لإنشاء أسماء الجلسات في Browserstack

يمكنك استخدام الخط + URI

تحليل العلامات لتحديد وتعيين دقة المستعرض الخاصة بالسيناريو

يمكنك استخدام خطوة لهذا.

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

charlierudolph شكرا على الرد. بالنسبة إلى الخادم المحاكي ، أجريت بالفعل محادثة سريعة مع بعض زملائي في العمل وكان استخدام "الخلفية" المشتركة في الاعتبار لإيجاد حل ، لذلك نعم يمكنك تجاوز تلك القائمة.

charlierudolph شكرا على الرد.

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

0) غير متسق مع نمط المراقب. يجب تزويد عمليات رد الاتصال بالبيانات التي يحتاجونها للسلوك الذي يدعمونه

1) يسبب هشاشة شديدة . يجب أن تكون الاختبارات موثوقة وإلا فلن يتم الوثوق بها. تتغير أرقام الأسطر وأسماء الملفات. سيؤدي ببساطة إضافة حرف إرجاع أو إزالته إلى كسر الاختبارات.

2) استخدام خطوات لتغيير الحالة ينتهك DRY. ضع في اعتبارك الحالة المتكررة لإضافة اختبارات A / B المميزة بعلامة. ما لم تقم بإضافة امتداد سطر الأوامر لتنفيذ الاختبارات بناءً على الخطوات التي تتضمنها ، فستتطلب الاختبارات كلا العلامة وخطواتها الداعمة والمعدلة للحالة.

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

4) تتعارض مع الخيار. تتعارض إضافة خطوات (جزء دلالي من الاختبار) لتغيير حالة الميزة مع نية خيار عزل كاتب الاختبار. إذا لم يتغير السلوك ، فلا ينبغي للاختبار.

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

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

charlierudolph ، كنت أفكر ، حل آخر ...
عند إنشاء كائن World ، قم بتوفير مرجع لكائن السيناريو المستخدم للاختبار.

نظرًا لأن العالم متاح كـ "this" لجميع عمليات الاسترجاعات ، فإنه سيحقق تكافؤًا كاملاً مع V2 (بشرط إعطاء رد نداء AfterAll النتائج)

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

1. لم أسمع أبدًا أن نمط المراقب هو هدف تصميم للخيار.
2. تكون أسماء السيناريوهات هشة أيضًا لأن تغيير حرف واحد يغيرها أيضًا. أوافق على كسر رقم الملف / السطر عند اتخاذ ما يشبه الإجراءات غير ذات الصلة. كنت أقترح الاستخدام في الإبلاغ عن النتائج وليس في إجراء الاختبارات وبالتالي لا يكون للجزء الهش تأثير سلبي كبير.
3. Using Steps to alter State violates DRY لا أفهم هذا. يتم استخدام العلامة لتحديد الميزات ويتم استخدام الخطوة للإعداد / الإجراءات / التوقعات. هذه أغراض مختلفة. لدينا الحد الأدنى من الدعم لاستخدام العلامة للإعداد مع الخطافات ذات العلامات ولكنها ليست مصممة للتعامل مع التعقيد.
4. كنت أقترح فقط تحليل إخراج المنسق لإعداد التقارير. لا ينبغي أن تشارك في إجراء الاختبارات.
5. Adding Steps (a semantic part of the test) to alter the Feature's state is counter to intent of Cucumber of isolating test writer لا أفهم هذا أيضًا. إذا كنت لا تستطيع استخدام الخطوات لأداء الإجراءات وتعيين الحالة ، فكيف تجري الاختبارات؟
6. Tags are metadata ABOUT the test, it is semantically consistent to use them to alter the state in which the test will run . أنا لا أوافق على أن تكون متسقة. العلامات بالنسبة لي هي فقط لتحديد الاختبارات. هناك دعم لتغيير الحد الأدنى من الحالة ولكن ليس للتغيير المعقد للحالة مع المعلمات.

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

charlierudolph ،

شكرا لأخذ الوقت الكافي لمناقشة هذه المسألة. إنني أقدر حقًا العمل الذي قمت به لتزويدنا بـ Cucumber-js. ولكن كما هو الحال لا يمكنني الترقية إلى V3.

أنا لا أنوي أن أكون قتالية. أنا قلقة فقط وقد تظهر في ردودي.

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

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

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

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

2. ليس لدي أي اعتماد على الأسماء الفعلية. ولكن نظرًا لأنها فريدة ، فهي وسيلة لبناء اسم جلسة ذي مغزى للمستخدم في Browserstack.

3. سمح لي الوصول إلى مجموعة العلامات خلال "قبل" ببناء بنيات قابلة لإعادة الاستخدام لتغيير الحالة (مثل إعداد معلمات URL على النحو الأمثل) دون تعديل الاختبار (إضافة خطوات). هذا يعني أنه كان هناك ارتباط 1-1 بين الاختبارات التي أردت تشغيلها (العلامات) وإعدادها. جاف.

4. لقد أعربت عن قلقك من أن المطورين أصبحوا معتمدين على التنفيذ ، ولكن الحل الذي تقدمه لإزالة حالة المراقبة الضرورية هو جعل المطور يعتمد على التنفيذ الآخر (تنسيق الملف)؟ كيف يمكن أن يكون إجبار المستخدم على القيام بملفات تحليل العمل المملة والبطيئة والمعرضة للخطأ أفضل من الوصول إلى ملكية الدولة؟

5. من الواضح أن الخطوات تحدد حالة الاختبار. لكن أحد أهداف تصميم Cucumber كان أن الشخص الذي يكتب الخطوات يجب أن يكون معزولًا عن التنفيذ الأساسي. اختبار EG السلوك الدلالي دون التورط في التفاصيل الأساسية. يبدو أن إضافة خطوات لتغيير معلمات الاستعلام ، وتحديد الجهاز / المتصفح / نظام التشغيل ، يتعارض مع هذا الهدف.

6. بالنسبة لك ، فإن العلامات تتعلق فقط بتحديد الاختبارات. لكن Cucumber Wiki له العديد من الاستخدامات للعلامات.

7. التنظيم والتجميع
8. المرشحات (تشغيل المجموعات عبر سطر الأوامر)
9. روابط للمستندات ذات الصلة (مثل Optimizely flags)
10. الإشارة إلى مكان وجود الميزة في العملية

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

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

charlierudolph شكرا

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

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

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

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

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

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

FWIW ، cucumber-ruby له نقطتان تمديد أعتقد أنهما يرضيان مبدأ "الأشياء السهلة يجب أن تكون سهلة ، والأشياء الصعبة يجب أن تكون ممكنة" وقد تكون الأفكار التي يمكن أن تساعد في حالات الاستخدام هذه.

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

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

HTH

لقد أدركت للتو أن التوثيق وراء هذا الارتباط للفلاتر أمر مروع! آسف. لا وقت لإصلاحه الآن ، ولكن هناك بعض الأمثلة الأخرى هنا: http://www.rubydoc.info/github/cucumber/cucumber-ruby/Cucumber/Filters

مرحبًا charlierudolph ،

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

"هل يتضمن السيناريو الجاري تشغيله هذا النوع من الملفات الشخصية؟ ربما يمكنك جعل السيناريو يحفظ نوع الملف الشخصي الذي يتفاعل مع العالم ومن ثم يكون لديك علامة واحدة واضحة تطالب بإزالة الملف الشخصي المحفوظ؟"

لست متأكدا من أنني أتابع.

وأنا أفهم أنه ربما توجد طرق أخرى للحصول على نفس الحل بدون نتيجة الاختبار القديمة. ولكن مما رأيته حتى الآن في هذه المحادثة هو أن كل البدائل تبدو أكثر تعقيدًا مما يجب أن تكون عليه. كانت نتيجة الاختبار القديمة تحتوي على الكثير من البيانات الوصفية حول السيناريو الذي كان على وشك التشغيل وكانت الطريقة الوحيدة للحصول على خطافات "معلمات". المنقلة كما هي مما رأيته وجربته لا تدعم حاليًا تشغيل ميزة من رقم سطر سيناريوهات. لذا فإن نتيجة testCase الجديدة لا أجد الكثير من المفيد بخلاف الحالة.

أود أن أرى testCase يطابق النتيجة التي تم إرجاعها عند استخدام getTestCasesFromFileSystem مع PickleFilter. لقد استخدمت هذا للقيام ببعض الأعمال الموازية المثيرة للاهتمام لدعم تصفية السيناريوهات حسب العلامة لتمريرها إلى المنقلة كأجزاء. المعلومات التي تم إرجاعها من هذه النتيجة أكثر فائدة وأعتقد أنه سيكون من المفيد للغاية الحصول عليها في نتيجة testCase.

مثال على نتيجة من PickFilter:

{ pickle: 
     { tags: [Object],
       name: 'Github test with page object',
       language: 'en',
       locations: [Object],
       steps: [Object] },
    uri: 'test/features/examples/github-example.feature' }

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

إذا كنت مهتمًا بمثالي ، فأنا أستخدمه هنا: https://github.com/gd46/dibellag-automation-framework/blob/master/configuration.js#L91

charlierudolph هل هذا هو المكان الذي يتم فيه تعيين testCase؟

https://github.com/cucumber/cucumber-js/blob/fbff6b0fae54d2e341ee247addc60a9f05753f1d/src/formatter/helpers/event_data_collector.js#L22

مما يمكنني قوله هناك إشارة إلى مخلل على طول حالة الاختبار. فلماذا لا تعيد عددًا قليلاً من البتات من نتيجة المخلل إلى نتيجة حالة الاختبار؟

@ gd46 حسنًا ، دعنا نضيف pickle إلى الكائن الذي يتم تمريره إلى الخطاف لاستبدال sourceLocation. يجب تحديث ذلك في هذه الوظيفة: https://github.com/cucumber/cucumber-js/blob/master/src/runtime/test_case_runner.js#L153

مرحبًا charlierudolph ، لقد رأيت للتو تعليقك. هذا سيكون رائع! سأحاول إلقاء نظرة على هذا قريبًا. يسعدني تقديم المساهمة.

charlierudolph أردت فقط توضيح التغيير. هل نحن بخير مع الاختلاف في أن المخلل يحتوي على uri بدون رقم السطر مباشرة كما هو الحال في sourceLocation. وإذا كان أي شخص يرغب في استهلاك uri برقم السطر ، يمكنه استخدام أرقام الأسطر المعادة من كائن المخلل؟ لا أرى أي مشكلة مع هذا أردت فقط التأكيد.

أعتقد دعونا نترك كائن موقع المصدر كما هو (بدلاً من إزالته) ونضيف كائن المخلل.

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

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

pickle: this.testCase.pickle

ثم يمكن لأي شخص يرغب في استهلاكه في الخطاف الوصول إليه على النحو التالي:

testCase.pickle.tags
testCase.pickle.name
etc. 

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

تمكنت من اختبار التغيير من خلال ربط مفترقتي بالتغييرات في أحد مشاريعي المحلية. ستبدو نتيجة testCase الكاملة كما يلي:

{
  "sourceLocation": {
    "uri": "test\/features\/examples\/example.feature",
    "line": 4
  },
  "pickle": {
    "tags": [
      {
        "name": "@example",
        "location": {
          "line": 3,
          "column": 3
        }
      }
    ],
    "name": "Custom Transform should take belly and capitalize it",
    "language": "en",
    "locations": [
      {
        "line": 4,
        "column": 3
      }
    ],
    "steps": [
      {
        "text": "I have cucumbers in my belly",
        "arguments": [

        ],
        "locations": [
          {
            "line": 5,
            "column": 10
          }
        ]
      }
    ]
  },
  "result": {
    "duration": 7,
    "status": "passed"
  }
}

بعد إجراء المزيد من الاختبارات ، لاحظت أن المخلل لا يحتوي على uri في الوقت الذي يمكننا الوصول إليه في test_case_runner. لذلك أعتقد أنه من الجيد الاحتفاظ بموقع المصدر كما هو.

هذا ما يعيده PickleFilter للمخلل على النحو التالي:

{
    "pickle": {
      "tags": [
        {
          "name": "@example",
          "location": {
            "line": 3,
            "column": 3
          }
        }
      ],
      "name": "Custom Transform should take belly and capitalize it",
      "language": "en",
      "locations": [
        {
          "line": 4,
          "column": 3
        }
      ],
      "steps": [
        {
          "text": "I have cucumbers in my belly",
          "arguments": [

          ],
          "locations": [
            {
              "line": 5,
              "column": 10
            }
          ]
        }
      ]
    },
    "uri": "test\/features\/examples\/example.feature"
  }

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

تم فتح العلاقات العامة لتسليط الضوء على التغييرات حتى الآن. لا تزال بحاجة إلى تحديث الاختبارات.

العمل على تحديث الاختبارات. لدي إعداد هذا الشيء لتغيير إصدار جافا المحلي الخاص بي وأدركت أن هذا هو سبب عدم تمكني من تشغيل بعض اختبارات الميزات: /.

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