Cucumber-js: लागू करें -- पुनः प्रयास करें

@ericyliu यह ककड़ी 3 में आ रहा है। निश्चित नहीं है कि ककड़ी 2 अभी भी आरसी में क्यों है ... यह 2 साल से बाहर है

@charlierudolph या कोई भी अगर आपके पास कोई संकेत था तो मुझे इसे लेने और इसे जाने देने में खुशी होगी।

मेरा अनुमानात्मक दृष्टिकोण यह होगा कि चल रहे परिदृश्य के अंत में हम बता सकते हैं कि यह विफल हुआ है या नहीं और इसे फिर से चलाएँ (पुन: प्रयास की गई गिनती के लिए कुछ राज्य रखते हुए)। मैं इसमें कहां फंस सकता हूं?

साथ ही साथ मैं पूरी प्रक्रिया के अंत में सभी परिदृश्यों की एक सूची तक पहुंचने में सक्षम होने की उम्मीद करता हूं, जितनी बार उन्होंने पुनः प्रयास किया और उनकी अंतिम स्थिति यह हो सकती है ए) लॉग इन और बी) वांछित होने पर डिस्क पर डंप किया गया .

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

मैं

@charlierudolph कभी-कभी झिलमिलाहट परीक्षणों से निपटना असंभव है। उदाहरण के लिए, हमारे वातावरण में हमारे पास 23 अलग-अलग सेवाएं हैं जो हमारे एप्लिकेशन हिट करती हैं, और चूंकि हमारे पास उन सेवाओं का स्वामित्व नहीं है, उनमें से कोई भी किसी भी समय बंद हो सकता है। --retry ध्वज हमें परीक्षण को फिर से चलाने की अनुमति देता है ताकि एक अस्थायी सेवा आउटेज (जब वे सेवा को पुनरारंभ करें) हमारे परीक्षण सूट को विफल न करें।

इस सुविधा के साथ व्यक्तिगत असहमति के संबंध में (यह तर्क इंजीनियरिंग की दुनिया में टैब बनाम रिक्त स्थान के रूप में बेकार हो सकता है), यदि एक टूलिंग युक्ति के रूप में ककड़ी इसे लागू कर रही है तो हमें इस उपकरण के जेएस संस्करण में भी इसका समर्थन करना चाहिए।

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

वास्तविक दुनिया में सक्रिय कार्रवाई के लिए फ्लेकीनेस की पहचान करने के लिए अच्छी ट्रैकिंग के अतिरिक्त असफल परीक्षणों को पुनः प्रयास करने में सक्षम होना बहुत मूल्यवान है।

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

इसमें जोड़ने के लिए cucumber-js already में rerun कार्यक्षमता है जो मूल रूप से केवल एक पुनः प्रयास है लेकिन कम कुशल है क्योंकि इसे एक अलग प्रक्रिया के रूप में चलाया जाना है (यह इसे सही ढंग से समझने में प्रदान कर रहा है)। पुन: प्रयास करना एक बेहतर समाधान है।

cc @charlierudolph

यह वास्तविक दुनिया में भी व्यापक परीक्षण सूट और जटिल अनुप्रयोगों के साथ है जो फ्लेकीनेस के खिलाफ 100% की रक्षा करना असंभव है और इसलिए अविश्वसनीय रूप से महंगा हो जाता है।

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

इस ककड़ी-जेएस में जोड़ने के लिए पहले से ही कार्यक्षमता फिर से शुरू हो गई है जो मूल रूप से केवल एक पुनः प्रयास है लेकिन कम कुशल है क्योंकि इसे एक अलग प्रक्रिया के रूप में चलाया जाना है (यह इसे सही ढंग से समझ रहा है)। पुन: प्रयास करना एक बेहतर समाधान है

Rerun बनाया गया था ताकि आप आसानी से उन परीक्षणों पर ध्यान केंद्रित कर सकें जिन्हें ठीक करने की आवश्यकता है। हां, आप इसका उपयोग केवल असफल परिदृश्यों को पुनः प्रयास करने के लिए कर सकते हैं।

मैं 100% सहमत हूं कि परतदार परीक्षणों से बचने के लिए कुछ है। कहा जा रहा है, एक परीक्षण की चंचलता अक्सर कुछ ऐसी होती है जो एक टीम के नियंत्रण में नहीं होती है। यहाँ मेरी स्थिति है;

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

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

मुझे लगता है कि हमें इस पर पुनर्विचार करना चाहिए। खीरा-रूबी के पास अब है।

माना। रूबी कार्यान्वयन के लिए कोड यहां दिया गया है। जेएस कार्यान्वयन के लिए उपयोगी हो सकता है। https://github.com/cucumber/cucumber-ruby/pull/920/files

हाय सब लोग, क्या ककड़ी-जेएस में अब 'पुनः प्रयास' सुविधा उपलब्ध है? जितना मैं मानता हूं कि परतदार परीक्षणों को ठीक किया जाना चाहिए, अनुभव बताते हैं कि बड़ी परियोजनाओं में काम करते समय कई बाहरी निर्भरताओं के साथ काम करना हमेशा संभव नहीं होता है।
दिन के अंत में, यदि इस तरह के एक परतदार परीक्षण मामले को लापता रिट्रियल लॉजिक के कारण स्वचालन द्वारा कवर नहीं किया जा सकता है, तो इसे वैसे भी मैन्युअल रूप से परीक्षण करना होगा।
मेरा मानना ​​​​है कि पुनः प्रयास तर्क का उपयोग ककड़ी उपयोगकर्ता के लिए एक विकल्प के रूप में छोड़ दिया जाना चाहिए।
मुझे 'पुन: चलाएँ' सुविधा के बारे में पता है, लेकिन इसका उपयोग करने से अतिरिक्त जटिलता जुड़ जाती है क्योंकि ककड़ी धावक पारदर्शी रूप से आपके लिए इसे करने के लिए परीक्षणों को अलग से फिर से चलाना पड़ता है।

हाय @charlierudolph और @aslakhellesoy। इस सुविधा के साथ कोई प्रगति?

मेरी जानकारी में कोई इस पर काम नहीं कर रहा है। अगर कोई पुल अनुरोध प्रदान करता है तो मैं इसे जोड़ने पर विचार करूंगा।

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

वह महान होगा! कृपया इसे उसी तरह से व्यवहार करने का प्रयास करें जैसे ककड़ी-रूबी में। यदि यह इससे अलग हो जाता है तो हम इसका विलय नहीं कर सकते, क्योंकि समेकन/संगति एक ऐसी चीज है जिसके लिए हम प्रयास कर रहे हैं।

हाय @aslakhellesoy , मैंने आधार पुनः प्रयास कार्यक्षमता को CLI --retry विकल्प के रूप में लागू किया है। मैंने इसे अपनी परियोजना के साथ काम पर परीक्षण किया है और यह अच्छी तरह से काम करता है। मुझे अपनी कार्य शाखा को आगे बढ़ाने और कार्यान्वयन पर चर्चा करने के लिए पीआर खोलने के लिए अनुमतियों की आवश्यकता होगी। मुझे बताएं, धन्यवाद।

@hurrikam बढ़िया काम .. 👏👏👏
मैं भी इसका उपयोग करने के लिए उत्सुक हूं। मैं नाइटवॉच-ककड़ी का उपयोग कर रहा हूं और वे इसे ककड़ी जेएस में तय करने की प्रतीक्षा कर रहे हैं। संदर्भ # https://github.com/mucsi96/nightwatch-cucumber/issues/213

@charlierudolph क्या आप कृपया इसमें मदद कर सकते हैं? मैं इस समय अपना पीआर जमा नहीं कर सकता।

@hurrikam आप एक कांटा बना सकते हैं और अपना कोड वहां https://help.github.com/articles/fork-a-repo/

@charlierudolph कृपया PR-1114 देखें
जैसा कि शीर्षक में उल्लेख किया गया है, यह मौजूदा स्वरूपकों और रिपोर्टों को तोड़े बिना सुविधा को प्राप्त करने के लिए न्यूनतम कार्यान्वयन (वास्तव में बहुत कम कोड परिवर्तन) है।

मैं ककड़ी रूबी रेपो में कुछ पुरानी बातचीत के माध्यम से चला गया कि क्या एक परतदार परीक्षण के प्रत्येक रन की सूचना दी जानी चाहिए, संभवतः पिछले रनों के लिए एक 'परतदार' परिणाम की स्थिति पेश करना। सुनिश्चित नहीं है कि अगर ऐसा किया गया था और फिर से, ड्रॉ बैक एक ही टेस्ट केस के सभी प्रयासों को लॉग में लाने के लिए होगा।

आइए इसकी चर्चा करते हैं।

@hurrikam मेरी टीम ने पीआर का एक कांटा लिया है ताकि हम यह कार्यक्षमता प्राप्त कर सकें। यह अब तक वास्तव में अच्छा काम कर रहा है। मुझे आशा है कि आप इसे जल्द ही विलय कर सकते हैं क्योंकि ध्वज एक बड़ी मदद है!

@ निक-लुकास यह कमाल है - क्या आपके पास वह है?

@thomaswmanion हाँ हम सक्रिय रूप से इस सुविधा का उपयोग कर रहे हैं। हमारे पास एक बैकएंड है जो कभी-कभी नौकरी की कतारों के माध्यम से थोड़ा घुट सकता है, इसलिए यह एक जीवनरक्षक रहा है।

पीआर का उपयोग करने के इच्छुक किसी भी व्यक्ति के लिए आप अपने पैकेज को इंगित कर सकते हैं। मेरे कांटे पर जेसन (या इसे मुझसे दूर कर सकते हैं):

  "dependencies": {
    "cucumber": "https://github.com/Nick-Lucas/cucumber-js.git#feature/issue-727-retry",
  },

खीरा पूर्व-निर्मित है इसलिए इसे केवल नोड_मॉड्यूल में स्थापित किया जा सकता है। यह बिना कहे चला जाना चाहिए कि निश्चित रूप से कोई वारंटी या समर्थन नहीं है क्योंकि यह सुविधा अभी तक प्री-अल्फा नहीं है

संपादित करें:

मैंने अब अपनी कंपनी छोड़ दी है और कांटा उनके जीथब को सौंप दिया है: https://github.com/wonderbill/cucumber-js.git#feature/issue -727-retry

अच्छा!!!! धन्यवाद @ निक-लुकास - इस समझ की सराहना करें कि सिस्टम के वातावरण प्रकृति में परतदार हो सकते हैं!

इसे मास्टर में विलय करने की आवश्यकता है, यह बंद नहीं है।

@thomaswmanion हाँ हम सक्रिय रूप से इस सुविधा का उपयोग कर रहे हैं। हमारे पास एक बैकएंड है जो कभी-कभी नौकरी की कतारों के माध्यम से थोड़ा घुट सकता है, इसलिए यह एक जीवनरक्षक रहा है।

पीआर का उपयोग करने के इच्छुक किसी भी व्यक्ति के लिए आप अपने पैकेज को इंगित कर सकते हैं। मेरे कांटे पर जेसन (या इसे मुझसे दूर कर सकते हैं):

  "dependencies": {
    "cucumber": "https://github.com/Nick-Lucas/cucumber-js.git#feature/issue-727-retry",
  },

खीरा पूर्व-निर्मित है इसलिए इसे केवल नोड_मॉड्यूल में स्थापित किया जा सकता है। यह बिना कहे चला जाना चाहिए कि _निश्चित रूप से कोई वारंटी या समर्थन_ नहीं है क्योंकि सुविधा अभी तक पूर्व-अल्फा नहीं है

संपादित करें:

मैंने अब अपनी कंपनी छोड़ दी है और कांटा उनके जीथब को सौंप दिया है: https://github.com/wonderbill/cucumber-js.git#feature/issue -727-retry

परीक्षण चलाते समय मैं पुनः प्रयास सुविधा कैसे चला सकता हूं?

@ricardgarcia केवल --retry विकल्प का उपयोग करें https://github.com/owncloud/phoenix/pull/1207/files देखें
हम यहां अपने पीआर से शाखा का उपयोग कर रहे हैं https://github.com/cucumber/cucumber-js/pull/1205 जब तक यह एक दिन उम्मीद से विलय नहीं हो जाता

हाय @ व्यक्तिगत-यह, उत्तर के लिए बहुत धन्यवाद। अगर मैं ककड़ी-जेएस पर अपने परीक्षण चलाने के लिए webdriverIO का उपयोग कर रहा हूं तो क्या यह काम करना चाहिए?
मैं "--retry 1" कमांड की कोशिश की है, लेकिन कोई पुनः किया जा रहा है।

@ricardgarcia जैसा कि https://github.com/cucumber/cucumber-js/pull/1205 में वर्णित है, इस फ़ंक्शन का उपयोग करने के लिए आप इसका उपयोग कर सकते हैं

"cucumber": "cucumber/cucumber-js#issue-727-retry"

चूंकि परिवर्तन अभी तक मुख्य ककड़ी रेपो में विलय नहीं हुए हैं।

हां @ जैन-नीरज मैंने इस संस्करण का उपयोग package.json में किया है और यह काम नहीं करता है, लेकिन जैसा कि मैंने उल्लेख किया है कि मैं webdriverIO पर ककड़ी का उपयोग करके परीक्षण चला रहा हूं, इसलिए निम्नलिखित ढांचा "wdio-cucumber-framework"। क्या यह किसी तरह काम करना चाहिए? यदि मैं ककड़ी-जेएस ढांचे का उपयोग करता हूं तो पुनः प्रयास करने के लिए मैं परीक्षण कैसे चला सकता हूं?

@ricardgarcia gitter https://gitter.im/cucumber/cucumber-js पर सहयोग करने देता है, मुझे इस मुद्दे को हल करने में आपकी मदद करने में सक्षम होना चाहिए।

@charlierudolph किसी भी मौके पर इसे मास्टर में मिला दिया जा सकता है?