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

परिदृश्य टैग जानने के लिए मेरे पास कई उपयोग के मामले भी हैं। निम्नलिखित सुडो उदाहरण को देखते हुए (गायब संस्करण सिंटैक्स थोड़ा सा है क्योंकि मेरे पास 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 में आफ्टर हुक में परिणाम वस्तु नहीं मिल रही है। मैंने टेस्टकेस, परिदृश्य परिणाम, और परिदृश्य की कोशिश की। क्या मैं कुछ भूल रहा हूँ?

हमारे पास एक ऐसा मामला है जहां हम अपने परीक्षण मामलों को टेस्टरेल में रखते हैं और हम उन्हें डाउनलोड करते हैं और रन से पहले फीचर फाइलों के रूप में सहेजते हैं।

फिर आफ्टर हुक में हम अपने SQL डेटाबेस को विस्तृत परीक्षा परिणाम भेजते हैं। उन परिणामों में शामिल हैं:

• टेस्टरेल से फीचर आईडी - एक टैग से लिया गया (प्रत्येक फीचर ने फीचर आईडी के साथ स्वचालित रूप से टैग जेनरेट किया है)
• अपवाद जो फेंका गया था - ककड़ी में scenario.getException() से लिया गया 1.x
• सभी टैग इस सुविधा के साथ टैग किए गए हैं
• चरण जो विफल रहे - हम प्रत्येक चरण का परिणाम प्राप्त करने के लिए stepResult हुक का उपयोग करते हैं
• टैग से ली गई फीचर आईडी का उपयोग करके टेस्टरेल से ली गई अन्य जानकारी का एक गुच्छा

तो ककड़ी 3.x में वर्तमान परिवर्तन के साथ हम कभी भी स्विच करने में सक्षम नहीं होंगे क्योंकि यह हमारे बुनियादी ढांचे को पूरी तरह से तोड़ देता है।

@pawelus मेरा बुनियादी ढांचा बिल्कुल वही काम करता है।
ऐसा लगता है कि चूंकि आप इन क्रियाओं को अतुल्यकालिक रूप से करने से कुछ भी नहीं खोते हैं (यानी आपका वास्तविक परीक्षण बुनियादी ढांचा टेस्टरेल अपडेट के बारे में "परवाह" नहीं करता है), आप उस कोड को कस्टम फॉर्मेटर में ले जा सकते हैं, और घटना से आने वाली जानकारी का उपयोग कर सकते हैं रिपोर्ट बनाने और भेजने के लिए प्रोटोकॉल।

व्यक्तिगत रूप से मेरे पास एक रैपर स्क्रिप्ट है जो ककड़ी लॉन्च करती है।
यह ककड़ी लॉन्च होने से पहले टेस्टरेल परिदृश्यों को डाउनलोड करता है, इसलिए टेस्टरेल रिपोर्ट कोड को ककड़ी हुक से और रैपर स्क्रिप्ट में स्थानांतरित करना मेरे लिए कोई बड़ी समस्या नहीं थी।
ककड़ी के पूरा होने के बाद, स्क्रिप्ट आउटपुट किए गए ककड़ी परिणाम JSON को पढ़ती है, और वहां से आवश्यक सभी सूचनाओं को संकलित करती है।

ऐसा लगता है कि आपको अपना कोड किसी भी तरह से पुनर्व्यवस्थित करना होगा।
मुझे लगता है कि सभी पूर्व/पोस्ट क्रियाओं को एक रैपर स्क्रिप्ट में ले जाना एक अच्छा समाधान है जो वी 3 में खोए गए कुछ नियंत्रण को पुनर्स्थापित करता है।
यह अभी भी कुछ हद तक दर्द है, क्योंकि मुझे आउटपुट परिणामों को समृद्ध करने के लिए महत्वपूर्ण संदर्भ जानकारी को क्रमबद्ध करना है (क्योंकि प्रासंगिक कोड चलने के समय मेरी आधारभूत संरचना स्थिति नष्ट हो जाती है), लेकिन यह करने योग्य है।

मुझे लगता है कि हुक में टैग जानने की क्षमता खोना शर्म की बात होगी। यह थोड़ा और विन्यास योग्य बनाने का एकमात्र तरीका था क्योंकि आप इसे पैरामीटर पास नहीं कर सकते हैं मैं अतिरिक्त टैग जोड़ रहा था और फिर देखें कि विभिन्न इनपुट के साथ फ़ंक्शन को कॉल करने के लिए वर्तमान परिदृश्य पर कौन से लागू किए गए थे।

@yaronassa हम

प्रोट्रैक्टर शुरू होने से पहले हम सुविधाओं को डाउनलोड करते हैं, लेकिन डेटाबेस को परिणाम भेजना एक अलग कहानी है।

सेलेनियम ग्रिड पर चलने वाले शार्डिंग और परीक्षणों और असफल सुविधाओं के पुन: चलाने के साथ डेटाबेस में परिणामों को सही क्रम में प्राप्त करने के लिए यह काफी परेशानी और जटिल तर्क होगा। खीरे 1 और 2 में हमारे पास मौजूद क्षमताओं को बहाल करने के लिए काफी मात्रा में काम किया गया।

केवल चरण परिणाम प्राप्त करने के लिए एक कस्टम फॉर्मेटर बनाना भी सही नहीं लगता है।

अरे, मैं तुम्हारे साथ हूँ।
मैं ककड़ी की वर्तमान स्थिति तक अप्रतिबंधित पहुंच चाहता था - फीचर, परिदृश्य और चरण, इसके संपूर्ण संपत्ति संग्रह के साथ, और पहुंच लिखने के लिए (मैं परिदृश्यों के भविष्य के "कॉल स्टैक" तक पहुंच भी चाहता हूं, इसे पहले से हेरफेर करने की क्षमता के साथ )

यह देखते हुए कि ककड़ी जेएस जानबूझकर इस तरह की "आंतरिक दृश्यता" से दूर जा रहा है, मैं ऐसे समाधान पेश कर रहा हूं जो मुझे लगता है कि निकट भविष्य में काम कर सकते हैं। व्यक्तिगत रूप से, मुझे लगता है कि एक समय आएगा जब हम जैसे टिंकरर्स को इस तरह की पहुंच बनाए रखने के लिए ककड़ी के आंतरिक तरीकों को ओवरराइड करने का सहारा लेना होगा।
और यह ठीक है - मुझे लगता है कि हम में से एक दर्जन, और हजारों अधिक आकस्मिक उपयोगकर्ता हैं।

यदि संभव हो तो मैं परिदृश्य का नाम भी वापस कर दूंगा। वास्तव में मैं एक स्नैपशॉट क्षमता जोड़ रहा हूं और मुझे अपने स्नैपशॉट का नाम देने के लिए परिदृश्य का नाम जानने की आवश्यकता है।

@ 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 परिवर्तनों का एक उपोत्पाद यह है कि पार्सिंग परिणाम समर्थन फ़ाइलों से बाहर और स्टैंडअलोन प्रक्रियाओं में चले जाते हैं। मुझे लगता है कि यह चीजों का बेहतर अलगाव है और आदर्श रूप से चीजों को मूल रूप से कैसे बनाया गया था।

@bnadim

आप attach फ़ंक्शन के साथ स्क्रीनशॉट जोड़ सकते हैं ताकि उन्हें इवेंट पोटोकॉल / जेसन फॉर्मेटर्स में आउटपुट किया जा सके और फिर परिदृश्य नाम के आधार पर फाइलों को सहेजने के लिए कुछ पोस्ट प्रोसेसिंग करें। साइड नॉट: परिदृश्य नाम अद्वितीय होने की गारंटी नहीं है जबकि परिदृश्य यूरी और लाइन नंबर हैं।

@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);

मुझे इस पर अपने विचार बताएं? मुझे विश्वास है कि कुछ मामलों में आपका उदाहरण आसान प्रतिस्थापन होगा। लेकिन दूसरों में जहां कई अतिरिक्त कदम उठाने की आवश्यकता है, आप इन सभी चरणों को संभावित रूप से डुप्लिकेट कर सकते हैं।

मेरा उपयोग मामला यह है कि मैं टैग के आधार पर प्रत्येक परिदृश्य के लिए एक मॉकसर्वर सेट करता हूं, मुझे पता है कि इसे कैसे व्यवहार करना चाहिए। विशिष्ट टैग किए गए परिदृश्यों के लिए हुक जोड़ना बहुत रखरखाव-गहन है, क्योंकि मुझे प्रत्येक परिदृश्य के लिए एक हुक जोड़ने की आवश्यकता है जिसका मैं समर्थन करता हूं ...

हम परिदृश्य के नाम को लॉग करने के लिए अपने पहले और बाद के हुक में भी परिदृश्य.नाम का उपयोग कर रहे हैं। इस तरह हम देख सकते हैं कि परीक्षण के परिणामों का विश्लेषण करते समय एक निश्चित परिदृश्य कब शुरू और समाप्त होता है। यह परिवर्तन उस सुविधा को तोड़ देता है।

मैं सेलेनियम ड्राइव करने के लिए ककड़ी-जेएस का उपयोग कर रहा हूँ। स्थानीय और ब्राउज़रस्टैक दोनों

मैं कई आवश्यक चीजों के लिए परीक्षण स्थिति (सुविधा, परिदृश्य, टैग, परिणाम, आदि) का उपयोग कर रहा था।

• URL के परिदृश्य-विशिष्ट परिवर्तन करने के लिए
• वर्तमान ब्राउज़र कॉन्फ़िगरेशन के आधार पर गतिशील रूप से परीक्षण छोड़ें
• परीक्षण परिणामों को वापस ब्राउज़रस्टैक पर रिकॉर्ड करने के लिए परिदृश्य-विशिष्ट URL का उपयोग करें
• ब्राउज़रस्टैक में सत्र नाम उत्पन्न करने के लिए फ़ीचर और परिदृश्य नामों का उपयोग करें
• परिदृश्य विशिष्ट ब्राउज़र रिज़ॉल्यूशन को पहचानने और सेट करने के लिए टैग को पार्स करें

इन सभी को ऐप्स में लपेटा गया था ताकि समग्र रन टाइम को कम करने के लिए समवर्ती इंस्टेंस को सक्षम किया जा सके।

ये क्यों गिराए गए?
क्या वे कभी वापस नहीं आ रहे हैं?

@ जीडी46

क्या चल रहे परिदृश्य में उस प्रकार की प्रोफ़ाइल शामिल है? हो सकता है कि आपके पास परिदृश्य हो कि किस प्रकार की प्रोफ़ाइल दुनिया के साथ इंटरैक्ट कर रही है और फिर आपके पास एक ही स्पष्ट टैग है जो सहेजी गई प्रोफ़ाइल को हटाने का संकेत देता है?

@justusromijn

आपके लिए नकली सर्वर क्या आप सेटअप को टैग के आधार पर एक चरण का उपयोग करके स्थानांतरित कर सकते हैं जो परिभाषित करता है कि सेटअप क्या है? फिर आप आसानी से पैरामीटर कर सकते हैं।

@Jordyderuijter

आप परिदृश्य रेखा और यूरी लॉग कर सकते हैं (जो वास्तव में अद्वितीय है और आपको परिदृश्य नाम की खोज करने से रोकता है)।

@leggebroten

URL के परिदृश्य-विशिष्ट परिवर्तन करने के लिए

आप इसके बजाय एक चरण का उपयोग कर सकते हैं या अद्वितीय टैग का उपयोग कर सकते हैं

वर्तमान ब्राउज़र कॉन्फ़िगरेशन के आधार पर गतिशील रूप से परीक्षण छोड़ें

आप गतिशील रूप से परीक्षण कैसे छोड़ रहे थे? #912 इसके लिए समर्थन जोड़ता है

परीक्षण परिणामों को वापस ब्राउज़रस्टैक पर रिकॉर्ड करने के लिए परिदृश्य-विशिष्ट URL का उपयोग करें

आप नाम की जगह लाइन और यूरी का इस्तेमाल कर सकते हैं। जैसा कि पहले उल्लेख किया गया है, लाइन और यूरी की गारंटी अद्वितीय है जबकि नाम नहीं है। मैं परीक्षण परिणामों के लिए जेसन फॉर्मेटर या इवेंट प्रोटोकॉल फॉर्मेटर फॉर्मेटर को पार्स करने और संलग्नक का उपयोग करने का भी सुझाव देता हूं यदि आपको कुछ भी जोड़ने की आवश्यकता है।

ब्राउज़रस्टैक में सत्र नाम उत्पन्न करने के लिए फ़ीचर और परिदृश्य नामों का उपयोग करें

आप लाइन + URI . का उपयोग कर सकते हैं

परिदृश्य विशिष्ट ब्राउज़र रिज़ॉल्यूशन को पहचानने और सेट करने के लिए टैग को पार्स करें

इसके लिए आप एक स्टेप का इस्तेमाल कर सकते हैं।

इन सभी उदाहरणों से, मेरे पास अभी तक एक उपयोग का मामला नहीं है जो मुझे आश्वस्त करता है कि हमें हुक में टैग या नाम वापस जोड़ना चाहिए। ऐसा लगता है कि टैग और नाम होने से कुछ चीजें करना आसान हो गया है, लेकिन मुझे लगता है कि उन्हें पूरा करने के और भी तरीके हैं जो मेरे लिए अधिक मायने रखते हैं

@charlierudolph उत्तर के लिए धन्यवाद। मॉकसर्वर के लिए मैंने पहले से ही कुछ सहकर्मियों के साथ एक त्वरित बातचीत की थी और एक साझा "पृष्ठभूमि" का उपयोग करना एक समाधान के लिए विचार में था, इसलिए हाँ आप सूची में से एक को पार कर सकते हैं।

@charlierudolph उत्तर के लिए धन्यवाद।

जबकि चरण और पार्सिंग आउटपुट का उपयोग करने के आपके सुझाव काम करने के लिए किए जा सकते हैं, यह उन पूर्व संस्करणों से बहुत कम है जहां कॉलबैक के पास परीक्षण राज्य तक पहुंच है।

0) ऑब्जर्वर पैटर्न के साथ असंगत। कॉलबैक को उनके द्वारा समर्थित व्यवहार के लिए आवश्यक डेटा प्रदान किया जाना चाहिए

1) अत्यधिक नाजुकता को प्रेरित

2) राज्य को बदलने के लिए कदमों का उपयोग करना DRY का उल्लंघन करता है। टैग के साथ चिह्नित ए/बी परीक्षण जोड़ने के बार-बार होने वाले मामले पर विचार करें। जब तक आप उन चरणों के आधार पर परीक्षण निष्पादित करने के लिए कमांड लाइन एक्सटेंशन नहीं जोड़ते हैं, तो परीक्षणों के लिए दोनों टैग और उनके सहायक, राज्य-परिवर्तनकारी चरणों की आवश्यकता होगी।

3) डेवलपर को अतिरिक्त काम करने की आवश्यकता है। राज्य को खोजने के लिए आउटपुट को पार्स करना अनावश्यक, थकाऊ, त्रुटि प्रवण है, परीक्षण को आउटपुट स्वरूपों (खराब युग्मन) से बांधता है, और DRY का उल्लंघन करता है।

4) ककड़ी के साथ असंगत। फ़ीचर की स्थिति को बदलने के लिए चरण जोड़ना (परीक्षण का एक अर्थपूर्ण हिस्सा) अलग परीक्षण लेखक के ककड़ी के इरादे के विपरीत है। यदि व्यवहार नहीं बदला है, तो परीक्षण नहीं होना चाहिए।

5) यह घोषणात्मक नहीं है। टैग मेटाडेटा हैं परीक्षण के बारे में, यह परीक्षण चलाने की स्थिति को बदलने के लिए उनका उपयोग करने के लिए शब्दार्थ रूप से संगत है। जबकि चरण परीक्षण के भीतर अंतर्निहित हैं। आप परीक्षणों के एक समूह की पहचान उनके टैग से करते हैं... न कि उनके द्वारा उपयोग किए जाने वाले चरणों से।

ओह, और मैं वास्तव में "छोड़ने" परीक्षण नहीं कर रहा था, मैं परीक्षण चलाने से बचने के लिए कॉलबैक (शून्य, 'लंबित') का उपयोग कर रहा था। नया 'स्किप' फीचर बेहतर समाधान है।

@charlierudolph , मैं सोच रहा था, एक और उपाय ...
विश्व वस्तु का निर्माण करते समय, परीक्षण के लिए प्रयुक्त परिदृश्य वस्तु का संदर्भ प्रदान करें।

चूंकि विश्व सभी कॉलबैक के लिए "यह" के रूप में उपलब्ध है, यह वी 2 के साथ पूर्ण समानता प्राप्त करेगा (बशर्ते सभी कॉलबैक परिणाम दिए गए हों)

@leggebroten

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 । मैं इस बात से असहमत हूं कि यह सुसंगत है। मेरे लिए टैग केवल परीक्षणों की पहचान के लिए हैं। राज्य के न्यूनतम परिवर्तन के लिए समर्थन है, लेकिन मापदंडों के साथ राज्य के जटिल परिवर्तन के लिए नहीं।

सिस्टम में कोई और परिदृश्य वस्तु नहीं है। मुझे नहीं लगता कि v2 के साथ समानता एक लक्ष्य होना चाहिए। मुझे खुशी है कि यह बातचीत सामने आई और मैं अन्य समाधानों की तलाश में अच्छा हूं लेकिन मैं उस पर वापस नहीं जाना चाहता जो हमारे पास पहले था क्योंकि मेरा मानना ​​​​है कि उपयोगकर्ता ककड़ी के कार्यान्वयन पर अधिक भरोसा कर रहे थे, न कि इसके इंटरफेस पर।

@charlierudolph ,

इस मुद्दे पर चर्चा करने के लिए समय निकालने के लिए धन्यवाद। आपने हमें Cucumber-js प्रदान करने के लिए जो कार्य किया है, उसकी मैं वास्तव में सराहना करता हूँ। लेकिन जैसा कि यह खड़ा है मैं V3 में अपग्रेड नहीं कर सकता।

मेरा जुझारू होने का इरादा नहीं है। मैं बस चिंतित हूं और यह मेरे जवाबों में सामने आ सकता है।

पिछले संस्करण से केवल प्रलेखित इवेंट इंटरफ़ेस का उपयोग करते हुए, मैंने एक ऐसा ढांचा बनाया है जो ऑपरेटिंग सिस्टम/संस्करण, ब्राउज़र/संस्करण, डेस्कटॉप/ मोबाइल, और ऑप्टिमाइज़ली ए/बी परीक्षण।

मैं Steps का उपयोग नहीं कर सकता। बहुत देर हो चुकी है। परीक्षण शुरू होने से पहले डिवाइस प्रकार, ओएस/संस्करण और ब्राउज़र/संस्करण का निर्धारण किया जाना चाहिए या प्रत्येक परिदृश्य को "सेट अप ओएस" चरण और "ब्राउज़र सेट अप" चरण के लिए मजबूर किया जाएगा। यह ककड़ी के लक्ष्यों के साथ सीधे संघर्ष में है।

वैकल्पिक रूप से, जैसा कि मैंने पहले उल्लेख किया है, आप विश्व निर्माता को परिदृश्य जानकारी (फीचर यूआरआई, नाम, रेखा और टैग) प्रदान कर सकते हैं। यह शब्दार्थ रूप से विश्व वस्तु के इरादे के अनुरूप है और इनकैप्सुलेट और विस्तार करने के लिए सरल है। यह न केवल मेरे अधिकांश ईवेंट हैंडलर को समाप्त कर देगा, बल्कि क्योंकि हैंडलर का "यह" विश्व वस्तु है, यह ऑब्जर्वर पैटर्न के अनुरूप राज्य है।

1. मैंने यह नहीं कहा कि ऑब्जर्वर पैटर्न ककड़ी के लिए एक डिजाइन लक्ष्य था। केवल यह कि हुक और घटनाएँ प्रेक्षक हैं और, जैसे, उन्हें वह राज्य दिया जाना चाहिए जिसकी उन्हें अपना काम करने की आवश्यकता है। यह पैटर्न कॉलर के कार्यान्वयन और ईवेंट हैंडलर के बीच अलगाव की अनुमति देता है।

2. वास्तविक नामों पर मेरी कोई निर्भरता नहीं है। लेकिन चूंकि वे अद्वितीय हैं, वे ब्राउज़रस्टैक में संबंधित उपयोगकर्ता-सार्थक सत्र नाम बनाने के साधन हैं।

3. पहले के दौरान टैग के सेट तक पहुंच प्राप्त करने के बाद, मुझे परीक्षण को संशोधित किए बिना (चरणों को जोड़कर) राज्य को बदलने के लिए पुन: प्रयोज्य निर्माण (जैसे ऑप्टिमाइज़ली यूआरएल पैरामीटर सेट करना) की अनुमति दी। इसका मतलब था कि मेरे द्वारा चलाए जाने वाले परीक्षणों (टैग) और उनके सेटअप के बीच 1-1 सहसंबंध था। सूखा।

4. आपने चिंता व्यक्त की है कि डेवलपर्स कार्यान्वयन पर निर्भर हो रहे थे, फिर भी आवश्यक ऑब्जर्वर स्टेट को हटाने का आपका समाधान डेवलपर को अन्य कार्यान्वयन (फ़ाइल प्रारूप) पर निर्भर करना है? किसी उपयोगकर्ता को अधिक थकाऊ, धीमी और त्रुटि-प्रवण कार्य करने के लिए बाध्य करना राज्य की संपत्ति तक पहुँचने की तुलना में फ़ाइलों को पार्स करना बेहतर कैसे हो सकता है?

5. जाहिर है कदम परीक्षण राज्य की स्थापना कर रहे हैं। लेकिन ककड़ी के डिजाइन लक्ष्यों में से एक यह था कि चरणों को लिखने वाले व्यक्ति को अंतर्निहित कार्यान्वयन से अलग किया जाना चाहिए। ईजी अंतर्निहित विवरणों में उलझे बिना सिमेंटिक व्यवहार का परीक्षण करता है। क्वेरी पैरामीटर बदलने के लिए चरण जोड़ना, और डिवाइस/ब्राउज़र/ओएस को परिभाषित करना, इस लक्ष्य के विपरीत लगता है।

6. आपके लिए टैग केवल परीक्षणों की पहचान करने के बारे में हैं। लेकिन ककड़ी विकी के टैग के लिए कई उपयोग हैं।

7. आयोजन और समूह बनाना
8. फिल्टर (कमांड लाइन के माध्यम से चल रहे सेट)
9. संबंधित दस्तावेज़ों के लिंक (जैसे ऑप्टिमाइज़ली फ़्लैग)
10. यह इंगित करना कि प्रक्रिया में सुविधा कहाँ है

कॉलबैक से पहले टैग तक पहुंच होने से मुझे परीक्षण चलाने के लिए उपयोग किए जा रहे ब्राउज़र कॉन्फ़िगरेशन के आधार पर उपयुक्त स्थिति सुनिश्चित करने की अनुमति मिलती है। टैग का उपयोग उस घोषणात्मक बनाता है। कदमों का उपयोग करने से आशय बाधित होता है

पूर्व संस्करणों में इवेंट हैंडलर के कॉल और पैरामीटर इंटरफ़ेस थे। यदि देव आपके कोड को आपके कार्यान्वयन के लीक होने के साथ जोड़ते हैं, तो ईवेंट हैंडलर को केवल-पढ़ने के लिए "परिदृश्य" प्रॉक्सी पास करें।

@charlierudolph आपके उत्तर के लिए धन्यवाद

परिदृश्य के नाम भी नाजुक होते हैं क्योंकि एकल वर्ण परिवर्तन भी इसे बदल देता है। असंबंधित कार्रवाइयों की तरह महसूस करने पर मैं फ़ाइल/लाइन नंबर ब्रेक से सहमत हूं। मैं परिणामों की रिपोर्टिंग में उपयोग का सुझाव दे रहा था न कि परीक्षण चलाने में और इस प्रकार नाजुक हिस्से का अधिक नकारात्मक प्रभाव नहीं पड़ता है।

सच है, परिदृश्य नाम भी नाजुक होते हैं, लेकिन परिदृश्य को संदर्भित करने के लिए फ़ाइल और लाइन द्वारा संदर्भित करने की तुलना में यह बहुत कम नाजुक तरीका है। हम रन में विफलताओं का विश्लेषण करने और यह देखने के लिए कि क्या गलत हुआ, हम प्रतिदिन लॉगिंग में परिदृश्य नामों का उपयोग कर रहे हैं। यदि लॉगिंग केवल फ़ाइल और लाइन नंबर प्रदर्शित करता है तो यह परिदृश्य को वापस ट्रेस करने के लिए बहुत अधिक ओवरहेड का कारण बन जाएगा। इसके अलावा, अगर किसी ने फीचर फ़ाइल में बदलाव किया है या इस बीच परिदृश्य को कहीं और स्थानांतरित कर दिया है तो यह और भी जटिल हो जाएगा।

यदि लॉगिंग केवल फ़ाइल और लाइन नंबर प्रदर्शित करता है तो यह परिदृश्य को वापस ट्रेस करने के लिए बहुत अधिक ओवरहेड का कारण बन जाएगा।

यह अधिक उपरि कैसे है? आप फ़ाइल और लाइन नंबर जानते हैं और सीधे वहां जा सकते हैं। यदि आपके पास परिदृश्य का नाम है, तो आपको उस स्ट्रिंग को उस फ़ाइल और लाइन पर ले जाने के लिए खोजना होगा।

यह अधिक उपरि कैसे है? आप फ़ाइल और लाइन नंबर जानते हैं और सीधे वहां जा सकते हैं। यदि आपके पास परिदृश्य का नाम है, तो आपको उस स्ट्रिंग को उस फ़ाइल और लाइन पर ले जाने के लिए खोजना होगा।

जैसा कि मैंने कहा, अगर इस बीच फीचर फाइल बदल गई और परिदृश्य अब उस लाइन पर स्थित नहीं है। खासकर जब मैं पुराने टेस्ट रन के लॉग देख रहा हूं (उदाहरण के लिए 1 सप्ताह पहले)। इस मामले में मुझे गिट के माध्यम से जाना होगा और देखना होगा कि उस समय उस लाइन पर कौन सा परिदृश्य था।

एफडब्ल्यूआईडब्ल्यू, ककड़ी-रूबी के दो विस्तार बिंदु हैं जो मुझे लगता है कि "आसान चीजें आसान होनी चाहिए, कठिन चीजें संभव होनी चाहिए" के सिद्धांत को पूरा करती हैं और ऐसे विचार हो सकते हैं जो इन उपयोग-मामलों में मदद कर सकें।

सबसे पहले, हम प्रत्येक हुक के लिए RunningTestCase का एक उदाहरण पास करते हैं। यह एक अपरिवर्तनीय मूल्य वस्तु है जिसमें गेरकिन स्रोत (परिदृश्य / रूपरेखा / टैग आदि) के साथ-साथ परिदृश्य की वर्तमान परिणाम स्थिति के बारे में सभी जानकारी शामिल है। अपरिवर्तनीय होने का मतलब है कि हम उन मामलों पर विचार करने से सुरक्षित हैं जहां उपयोगकर्ता हम पर चीजों को बदलने और बदलने की कोशिश कर सकता है, लेकिन समान रूप से यह उन्हें इस बात पर पारदर्शिता देता है कि वर्तमान स्थिति क्या है।

दूसरा, हमारे पास फिल्टर हैं । फ़िल्टर आपको परीक्षण मामलों के निष्पादन से पहले स्ट्रीम में हेरफेर करने की अनुमति देते हैं। उदाहरण के लिए, हम ऐसे परीक्षण मामलों को स्ट्रीम से निकालने के लिए फ़िल्टर का उपयोग करते हैं जो CLI पर निर्दिष्ट टैग पैटर्न से मेल नहीं खाते। फिल्टर एक पावर-यूजर फीचर हैं।

एचटीएच

मुझे अभी एहसास हुआ कि फ़िल्टर के लिए उस लिंक के पीछे का दस्तावेज़ीकरण भयानक है! माफ़ करना। अब इसे ठीक करने का समय नहीं है, लेकिन यहां कुछ और उदाहरण हैं: http://www.rubydoc.info/github/cucumber/cucumber-ruby/Cucumber/Filters

हाय @charlierudolph ,

क्षमा करें, मुझे इस वार्तालाप पर अनुवर्ती कार्रवाई के बाद से कुछ समय हो गया है। क्या आप अपने बयान पर विस्तार से बता सकते हैं:

"क्या चल रहे परिदृश्य में उस प्रकार की प्रोफ़ाइल शामिल है? हो सकता है कि आप परिदृश्य को सहेज सकें कि किस प्रकार की प्रोफ़ाइल दुनिया से इंटरैक्ट कर रही है और फिर आपके पास एक ही स्पष्ट टैग है जो सहेजी गई प्रोफ़ाइल को हटाने का संकेत देता है?"

मुझे यकीन नहीं है कि मैं अनुसरण करता हूं।

और मैं समझता हूं कि पुराने परीक्षा परिणाम के बिना एक ही समाधान प्राप्त करने के अन्य तरीके हो सकते हैं। लेकिन इस बातचीत में मैंने अब तक जो देखा है, वह यह है कि सभी विकल्प अधिक जटिल लगते हैं, फिर उन्हें होने की आवश्यकता है। पुराने परीक्षा परिणाम में उस परिदृश्य के बारे में बहुत अधिक वर्णनात्मक डेटा था जो चलने वाला था और यह "पैरामीटरयुक्त" हुक रखने का एकमात्र तरीका था। प्रोटैक्टर जैसा कि मैंने जो देखा है और कोशिश की है वह वर्तमान में एक परिदृश्य लाइन नंबर से एक सुविधा को चलाने का समर्थन नहीं करता है। तो नए टेस्टकेस परिणाम में स्थिति के अलावा मुझे बहुत कुछ उपयोगी नहीं लगता है।

मैं टेस्टकेस को पिकलेफिल्टर के साथ getTestCasesFromFileSystem का उपयोग करते समय लौटाए गए परिणाम से मेल खाना चाहता हूं। मैंने इसका उपयोग कुछ दिलचस्प समानांतर कार्य करने के लिए किया है ताकि टैग द्वारा परिदृश्यों को शार्प के रूप में पास करने के लिए परिदृश्यों को फ़िल्टर किया जा सके। उस परिणाम से लौटाई गई जानकारी कहीं अधिक उपयोगी है और मुझे लगता है कि टेस्टकेस परिणाम में होना बेहद उपयोगी होगा।

पिकफिल्टर से उदाहरण परिणाम:

{ 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 क्या यह वह जगह है जहाँ टेस्टकेस सेट किया जा रहा है?

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

मैं जो बता सकता हूं उसमें साइड टेस्टकेस के साथ अचार का संदर्भ है। तो टेस्टकेस परिणाम पर अचार के परिणाम से कुछ और बिट्स क्यों नहीं लौटाते?

@ gd46 ठीक है, उस वस्तु में pickle जोड़ें जो स्रोत स्थान की जगह हुक को पास हो जाती है। इसे इस फ़ंक्शन में अपडेट करने की आवश्यकता है: https://github.com/cucumber/cucumber-js/blob/master/src/runtime/test_case_runner.js#L153

हाय @charlierudolph , मैंने अभी आपकी टिप्पणी देखी। वह महान होगा! मैं जल्द ही इस पर एक नज़र डालने की कोशिश करूँगा। मुझे योगदान करने में खुशी होगी।

@charlierudolph बस बदलाव को स्पष्ट करना चाहता था। क्या हम इस अंतर के साथ ठीक हैं कि अचार में सीधे बिना लाइन नंबर के उरी होता है जैसा कि स्रोत स्थान करता है। और अगर कोई लाइन नंबर के साथ यूरी का उपभोग करना चाहता है तो वे अचार ऑब्जेक्ट से लौटाए गए लाइन नंबरों का उपयोग कर सकते हैं? मुझे इसके साथ कोई समस्या नहीं दिख रही है, बस पुष्टि करना चाहता था।

मुझे लगता है कि चलो स्रोत स्थान वस्तु को छोड़ दें (इसे हटाने के बजाय) और अचार वस्तु जोड़ें।

ठीक है यह मेरे लिए भी काम करता है। तो मैं ककड़ी में योगदान करने के लिए नया हूं, मैं अभी भी संरचना को समझने की कोशिश कर रहा हूं।

जैसा कि आपने उस पंक्ति को इंगित किया है जिसे अद्यतन करने की आवश्यकता है, मेरा मानना ​​​​है कि हम स्रोत स्थान के बगल में कुछ इस तरह जोड़ सकते हैं:

pickle: this.testCase.pickle

फिर जो कोई भी हुक में इसका सेवन करना चाहता है, वह इसे निम्नानुसार एक्सेस कर सकता है:

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

मैंने अपडेट किया है लेकिन मुझे 100% यकीन नहीं है कि सभी संबंधित परीक्षणों को कैसे अपडेट किया जाए। क्या आप कुछ मार्गदर्शन दे पाएंगे?

मैं अपनी स्थानीय परियोजनाओं में से किसी एक में परिवर्तन के साथ अपने कांटे को जोड़कर परिवर्तन का परीक्षण करने में सक्षम था। पूरा टेस्टकेस परिणाम इस तरह दिखेगा:

{
  "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"
  }
}

कुछ और परीक्षण करने के बाद मैंने देखा कि अचार में उस समय यूरी नहीं होता है जब हमारे पास test_case_runner में इसकी पहुंच होती है। इसलिए मुझे लगता है कि स्रोत स्थान को यथावत रखना ठीक है।

अचारफिल्टर अचार को इस प्रकार लौटाता है:

{
    "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"
  }

तो सब कुछ वैसा ही होगा माइनस अचार जिसमें उरी न हो।

अब तक के बदलावों को उजागर करने के लिए एक पीआर खोला। अभी भी परीक्षणों को अद्यतन करने की आवश्यकता है।

परीक्षण अद्यतन करने पर काम कर रहा है। मेरे पास अपने स्थानीय जावा संस्करण को बदलने के लिए यह चीज़ सेटअप है और मुझे एहसास हुआ कि मैं कुछ फीचर परीक्षण चलाने में सक्षम क्यों नहीं था: /।

इस थ्रेड को स्वचालित रूप से लॉक कर दिया गया है क्योंकि इसे बंद करने के बाद हाल ही में कोई गतिविधि नहीं हुई है। कृपया संबंधित बग के लिए एक नया मुद्दा खोलें।