क्रॉस-लैंग्वेज टेस्ट-ड्रिवेन डेवलपमेंट

Question

संक्षिप्त प्रश्न: आप एक ऐसी परियोजना पर परीक्षण-संचालित विकास का पालन कैसे करते हैं जो कई भाषाओं में फैली हुई है?

विशेष रूप से, मैं एक वेब एप्लिकेशन लिख रहा हूं जो जावास्क्रिप्ट और पीएचपी का उपयोग करता है, और मैं टीडीडी सिद्धांतों का पालन करना चाहता हूं, लेकिन मुझे यकीन नहीं है कि उन्हें कैसे एकीकृत किया जाए। क्या मैं JS और PHP वर्गों के लिए अलग-अलग परीक्षण सूट चलाता हूं, और सर्वर प्रतिक्रियाओं का अनुकरण करने के लिए JS सुइट में नकली का उपयोग करता हूं? क्या एक रन में दोनों घटकों के यूनिट परीक्षण की तकनीक है?

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

मैं SimpleTest में अपने PHP परीक्षण और JsTestDriver में मेरे जावास्क्रिप्ट परीक्षण लिख रहा हूँ। मुझे ऑब्जेक्ट-ओरिएंटेड प्रतिमानों के लिए उपयोग किया जाता है, इसलिए मुझे PHP में कुछ कक्षाएं मिली हैं, और मैं प्रोटोटाइप इनहेरिटेंस का उपयोग करके जावास्क्रिप्ट में कुछ समान कर रहा हूं। मैंने इस किताब को Python में TDD के बारे में और जावास्क्रिप्ट में TDD के बारे में भी पढ़ना शुरू कर दिया है , लेकिन मैंने जो देखा है, उससे ये पूरी तरह से एक एप्लिकेशन का परीक्षण करने का वर्णन नहीं करता है (सेलेनियम या किसी अन्य वेब ड्राइवर की तरह कुछ का उपयोग करने के बाहर) फ्रंट-एंड स्वीकृति परीक्षण करने के लिए। क्या TDD को पूर्ण-स्टैक डेवलपर्स के लिए नहीं काटा गया है?

Comments

जब तक आपको SimpleTest का उपयोग करने के लिए मजबूर किया जा रहा है, मैं PHPUnit पर स्विच करने की सलाह दूंगा। सिंपलेस्टेस्ट बहुत सक्रिय नहीं लगता है और मॉकिंग और कोड कवरेज की बात करें तो यह थोड़ा पीछे रह जाता है।

— सेराड

Answer 1

क्या एक रन में दोनों घटकों के यूनिट परीक्षण की तकनीक है?

यह वास्तव में इकाई परीक्षण के विपरीत होगा - इकाई परीक्षण, विशेष रूप से टीडीडी शैली में, अलगाव में अपने घटकों का परीक्षण करने का मतलब है । इस प्रकार उत्तर हां है, "जेएस और पीएचपी वर्गों के लिए अलग-अलग परीक्षण सूट चलाएं ", अन्यथा यह इकाई परीक्षण नहीं है और न ही टीडीडी है।

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

Answer 2

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

इकाई परीक्षणों का एक महत्वपूर्ण हिस्सा अपनी निर्भरता से परीक्षण के तहत इकाई को अलग कर रहा है। इससे आपको दो महत्वपूर्ण लाभ मिलते हैं:

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

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

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

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

Comments

कूल, मैंने एटीडीडी को कभी नहीं देखा है लेकिन मैं बीडीडी के लिए बेहट और व्यवहार से परिचित हूं। मैं प्रतिक्रिया की सराहना करता हूं। फिर भी टीडीडी :) की सूक्ष्म-परीक्षण मानसिकता के आसपास मेरे सिर को लपेटने की कोशिश कर रहा है :)

— क्रिस ऑलसेन

@ChrisOlsen आपके सिर को पाने के लिए दो पहलू हैं: इकाई परीक्षण (बनाम एकीकरण या स्वीकृति) और जब आप उन्हें लिखते हैं (उत्पादन कोड के बजाय पहले)। यदि वे दोनों अजीब मानसिकता वाले लगते हैं, तो आप पहले दूसरे के साथ पकड़ पाने की कोशिश कर सकते हैं। बहुत सारे लोग TDD का अभ्यास नहीं करते हैं, लेकिन फिर भी बहुत गहन इकाई परीक्षण कवरेज पर जोर देते हैं।

— बेन आरोनसन

Answer 3

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

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

अंकल बॉब इस तरह से मुझसे बेहतर बताते हैं। https://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html