💺 🛀🏿 🧗🏽 हेनरिक नाइबेरग के लेख का अनुवाद "ट्रेंच से ATDD" (उन्नत के साथ ATDD) ⚡️ 🛢️ 👸🏼

मूल: www.infoq.com/articles/atdd-from-the-trenches

उन्नत के साथ ATDD

शुरुआती लोगों के लिए स्वीकृति परीक्षण के माध्यम से विकास

यदि आप कभी इस स्थिति में रहे हैं:

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

जो मैं करना चाहता था

कुछ दिनों पहले, मैंने webwhiteboard.com (मेरी परियोजना एक शौक है) के लिए पासवर्ड सुरक्षा बनाना शुरू कर दिया है। उपयोगकर्ता लंबे समय से पासवर्ड-सुरक्षित वर्चुअल व्हाईटबोर्ड की क्षमता को जोड़ने के लिए कह रहे हैं, इसलिए अब यह करने का समय है।
शब्दों में यह सरल लगता है, लेकिन वास्तव में आपको डिज़ाइन में काफी बदलाव करने की आवश्यकता है। अब तक, यह माना जाता है कि webwhiteboards.com का उपयोग अनाम उपयोगकर्ताओं द्वारा किया जाता है, बिना किसी उपयोगकर्ता नाम या पासवर्ड के। बोर्ड की सुरक्षा करने में कौन सक्षम होना चाहिए? कौन उसे एक्सेस कर पाएगा? अगर मैं अपना पासवर्ड भूल जाऊं तो क्या होगा? इसे सरल तरीके से कैसे लागू किया जाए, लेकिन एक ही समय में काफी विश्वसनीय तरीके से?
Webwhiteboard कोड यूनिट परीक्षणों और एकीकरण परीक्षणों द्वारा अच्छी तरह से कवर किया गया है।
लेकिन स्वीकृति परीक्षण, अर्थात्, अंत उपयोगकर्ता के दृष्टिकोण से सभी परतों से गुजरने वाले परीक्षण पूरी तरह से अनुपस्थित हैं।

डिजाइन पर विचार करें

वेबव्हाइटबोर्ड डिज़ाइन का मुख्य लक्ष्य सादगी है: पासवर्ड दर्ज करने की आवश्यकता को कम करने के लिए, खाते बनाने के लिए नहीं, कम अन्य परेशानियां। इसलिए मैंने पासवर्ड संरक्षित बोर्ड पर दो प्रतिबंध लगाए:

एक अनाम उपयोगकर्ता पासवर्ड बोर्ड की रक्षा नहीं कर सकता। लेकिन वह पहले से संरक्षित बोर्ड खोल सकता है। उसे सिस्टम में प्रवेश करने की आवश्यकता नहीं होगी, लेकिन केवल संरक्षित बोर्ड का पासवर्ड दर्ज करना होगा।
लॉगिन और पासवर्ड को एक बाहरी OpenId / Oauth घटक द्वारा प्रबंधित किया जाएगा, जो मूल रूप से Google द्वारा लक्षित है। इस प्रकार, उपयोगकर्ता को दूसरा खाता बनाने की आवश्यकता नहीं है।

कार्यान्वयन दृष्टिकोण

बहुत अनिश्चितता है। मुझे नहीं पता था कि यह कैसे काम करना चाहिए, न कि इसका उल्लेख कैसे करना चाहिए। यहाँ मैं क्या करने का फैसला किया है (ATDD ही):

चरण 1. प्रस्तावित प्रक्रिया का दस्तावेज।
चरण 2. इसे स्टार्टअप स्वीकृति परीक्षण में बदल दें
चरण 3. स्वीकृति परीक्षण चलाएं, सुनिश्चित करें कि यह गिर गया
चरण 4. मरम्मत स्वीकृति परीक्षण
चरण 5. कोड को साफ करें

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

चरण 1: प्रस्तावित प्रक्रिया का दस्तावेज

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

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

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

चरण 2: एक लॉन्च स्वीकृति परीक्षण में इसे चालू करें

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

चरण 2.1 सबसे आसान स्वचालित स्वीकृति परीक्षण लिखें

यहाँ वह स्क्रिप्ट है जिसे मैंने शुरू किया था:

कोई भी नहीं करने वाला बोर्ड खोलने का प्रयास करें
जांचें कि मैं उसे नहीं देख पा रहा हूं

ऐसी परीक्षा कैसे लिखें? किस ढांचे के साथ? क्या उपकरण? मुझे उपयोगकर्ता इंटरफ़ेस के माध्यम से परीक्षण करना चाहिए या नहीं? क्या मुझे परीक्षण में ग्राहक कोड शामिल करना चाहिए या सेवा को सीधे कॉल करना चाहिए?
सवालों का एक गुच्छा। चाल: उन्हें जवाब नहीं! बस बहाना है कि सब कुछ पहले से ही जादुई तरीके से किया गया है और बस छद्म कोड पर एक परीक्षण लिखें। उदाहरण के लिए:

public class AcceptanceTest { @Test public void openWhiteboardThatDoesntExist() { //1.     //2. ,       } }

मैंने इसे लॉन्च किया और यह पारित हो गया! हुर्रे! उम, लेकिन रुको, यह गलत है! टीडीडी त्रिकोण में पहला कदम ("रेड - ग्रीन - रिफैक्टिंग") लाल है। इसलिए मुझे यह साबित करने के लिए पहले परीक्षण करने की आवश्यकता है कि यह आवश्यकता अभी तक लागू नहीं हुई है।

शायद मैं कुछ वास्तविक कोड लिखकर शुरू करूँगा। फिर भी, छद्म कोड ने मुझे सही दिशा में एक कदम उठाने में मदद की।

चरण २.२ सबसे आसान स्वचालित स्वीकृति परीक्षण लाल करें

ऐसा करने के लिए, मैं AcceptanceTestClient वर्ग के साथ आया और जादुई रूप से सभी समस्याओं को हल करने का नाटक किया और मुझे अपनी स्वीकृति परीक्षण चलाने के लिए एक महान उच्च-स्तरीय इंटरफ़ेस प्रदान किया। यहां इसका उपयोग करना कितना आसान है:
client.openWhiteboard ("xyz");
assertFalse (client.hasWhiteboard ());
एक बार जब मैंने इस कोड को लिखा, तो मैं वास्तव में उस इंटरफ़ेस के साथ आया जो मेरी टेस्ट स्क्रिप्ट के लिए सबसे अच्छा काम करता है। परीक्षण में कोड की कई पंक्तियाँ होनी चाहिए क्योंकि छद्म कोड में था।
अगला, एक्लिप्स हॉटकीज़ का उपयोग करते हुए, मैंने स्वचालित रूप से एक खाली एक्सेप्टेंसटेक्स्ट क्लास और मेरी ज़रूरत के तरीकों को उत्पन्न किया:

 public class AcceptanceTestClient { public void openWhiteboard(String string) { // TODO Auto-generated method stub } public boolean hasWhiteboard() { // TODO Auto-generated method stub return false; } }

यहाँ परीक्षण वर्ग कैसा दिखता है:

 public class AcceptanceTest { AcceptanceTestClient client; @Test public void openWhiteboardThatDoesntExist() { //1.     client.openWhiteboard("xyz"); //2. ,       assertFalse(client.hasWhiteboard()); } }

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

चरण 2.3 सबसे आसान स्वचालित स्वीकृति परीक्षण ग्रीन बनाएं

अगला कदम स्वीकृति परीक्षण को हरा बनाने का है।

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

(विस्तार के लिए छवि पर क्लिक करें)
तकनीकी विवरण: वेब व्हाइटबोर्ड GWT (Google वेब टूलकिट) का उपयोग करता है। सब कुछ जावा में लिखा गया है, लेकिन GWT स्वचालित रूप से क्लाइंट कोड को जावास्क्रिप्ट में अनुवादित करता है, और एसिंक्रोनस क्लाइंट-सर्वर इंटरैक्शन के कार्यान्वयन के सभी निम्न-स्तरीय विवरणों को छिपाने के लिए जादुई रूप से आरपीसी (दूरस्थ प्रक्रिया कॉल) कॉल सम्मिलित करता है।
स्वीकृति परीक्षण शुरू करने से पहले, मैं सिस्टम को सीधे "बंद" करता हूं और सभी ढांचे, बाहरी घटकों और नेटवर्क इंटरैक्शन को काट देता हूं।

(विस्तार के लिए छवि पर क्लिक करें)
तो मैं एक AcceptTestClient बनाता हूं, जो कि वास्तविक ग्राहक कोड की तरह वेबव्हाइटबोर्ड सेवा से बात करता है। अंतर पर्दे के पीछे छिपे हुए हैं:

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

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

 public class AcceptanceTest { AcceptanceTestClient client; @Before public void initClient() { WhiteboardStorage fakeStorage = new FakeWhiteboardStorage(); WhiteboardService service = new WhiteboardServiceImpl(fakeStorage); client = new AcceptanceTestClient(service); } @Test public void openWhiteboardThatDoesntExist() { client.openWhiteboard("xyz"); assertFalse(client.hasWhiteboard()); } }

WhiteboardServiceImpl webwhiteboard सेवा का एक सही कार्यान्वयन है।
ध्यान दें कि AcceptanceTestClient निर्माता अब WhiteboardService (निर्भरता इंजेक्शन डिजाइन पैटर्न) का एक उदाहरण स्वीकार करता है। यह हमें एक अतिरिक्त दुष्प्रभाव देता है: यह कॉन्फ़िगरेशन के बारे में परवाह नहीं करता है। एक ही एक्सेप्टेंसटेक्स्टिएंट क्लास का उपयोग वास्तविक सिस्टम का परीक्षण करने के लिए किया जा सकता है, बस इसे एक वास्तविक आधार पर कॉन्फ़िगर किए गए व्हाइटबोर्ड सर्विस के एक उदाहरण को पास करके।

 public class AcceptanceTestClient { private final WhiteboardService service; private WhiteboardEnvelope envelope; public AcceptanceTestClient(WhiteboardService service) { this.service = service; } public void openWhiteboard(String whiteboardId) { boolean createIfMissing = false; this.envelope = service.getWhiteboard(whiteboardId, createIfMissing); } public boolean hasWhiteboard() { return envelope != null; } }

संक्षेप में, AcceptanceTestClient एक वास्तविक वेबव्हाइटबोर्ड वेब क्लाइंट की तरह व्यवहार करता है, जबकि एक ही समय में स्वीकृति परीक्षणों के लिए एक उच्च-स्तरीय इंटरफ़ेस प्रदान करता है।
आप पूछ सकते हैं, "अगर हमें पहले से ही एक व्हाइटबोर्ड सेवा है जिसे हम सीधे कॉल कर सकते हैं, तो हमें एक्सेप्टेंसटेक्स्ट की आवश्यकता क्यों है?" इसके 2 कारण हैं:

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

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

 @Test public void openWhiteboardThatDoesntExist() { myClient.openWhiteboard("xyz"); assertFalse(myClient.hasWhiteboard()); }

अगला कदम थोड़ा सा चुस्त करना है।

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

 @Test public void createNewWhiteboard() { client.createNewWhiteboard(); assertTrue(client.hasWhiteboard()); }

हुर्रे, हमारे पास एक परीक्षण ढांचा है! और बिना किसी फैशनेबल थर्ड-पार्टी लाइब्रेरी के। केवल जावा और जुनित।

चरण 2.4 पासवर्ड सुरक्षा के लिए स्वीकृति परीक्षण लिखें

अब पासवर्ड परीक्षण जोड़ने का समय आ गया है।
मैं छद्म कोड का उपयोग करके अपने परीक्षण के "विनिर्देश" का वर्णन करके शुरू करूंगा:

 @Test public void passwordProtect() { //1.     //2.     //3.     ,     //4.          //5.   ,       }

और अब, पहले की तरह, मैं टेस्ट कोड लिख रहा हूं, यह दिखाते हुए कि एक्सेप्टेंसटेक्स्टिएंट क्लास में पहले से ही मेरी जरूरत का सब कुछ है। यह तकनीक बेहद उपयोगी है।

 @Test public void passwordProtect() { //1.     myClient.createNewWhiteboard(); String whiteboardId = myClient.getCurrentWhiteboardId(); //2.      myClient.protectWhiteboard("bigsecret"); //3.     ,     try { joesClient.openWhiteboard(whiteboardId); fail("Expected WhiteboardProtectedException"); } catch (WhiteboardProtectedException err) { //  } assertFalse(joesClient.hasWhiteboard()); //4.          try { joesClient.openProtectedWhiteboard(whiteboardId, "wildguess"); fail("Expected WhiteboardProtectedException"); } catch (WhiteboardProtectedException err) { //  } assertFalse(joesClient.hasWhiteboard()); //5.   ,       joesClient.openProtectedWhiteboard(whiteboardId, "bigsecret"); assertTrue(joesClient.hasWhiteboard()); }

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

चरण 3 - स्वीकार टेस्ट रन और पतन करें

परीक्षण त्रिकोण के बाद, मेरा अगला कदम मेरी परीक्षा शुरू करने और असफल होने के लिए है।

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

चरण 4: स्वीकृति टेस्ट ग्रीन बनाएं

अब मुझे प्रोडक्ट कोड लिखना है। मैं सिस्टम में कई नई इकाइयाँ जोड़ रहा हूँ। कभी-कभी जो कोड मैंने जोड़ा था, वह बहुत ही मामूली था, इसलिए इसे यूनिट परीक्षणों के साथ कवर करना पड़ा। मैंने टीडीडी के साथ ऐसा किया। यह ATDD के समान है, लेकिन छोटे पैमाने पर।
यह कैसे ATDD और TDD एक साथ काम करते हैं। ATDD को बाहरी लूप मानें:

स्वीकृति परीक्षण लिखने के प्रत्येक चक्र के लिए (नई कार्यक्षमता के स्तर पर), हम इकाई परीक्षण (कक्षाओं और विधियों के स्तर पर) लेखन के कई चक्र करते हैं।

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

चरण 5 कोड साफ़ करें

हमेशा की तरह, एक बार स्वीकृति परीक्षण हरा हो गया है, यह सफाई करने का समय है। इस पर कभी नहीं बचा! यह खाने के बाद बर्तन धोने के बारे में है - इसे तुरंत करना सबसे अच्छा है।

मैं न केवल उत्पादन कोड, बल्कि परीक्षण कोड भी साफ कर रहा हूं। उदाहरण के लिए, मैंने एक हेल्पर विधि के रूप में एक गंदे प्रयास को पकड़ा, और मुझे एक साफ और स्वच्छ परीक्षण विधि मिली:

 @Test public void passwordProtect() { myClient.createNewWhiteboard(); String whiteboardId = myClient.getCurrentWhiteboardId(); myClient.protectWhiteboard("bigsecret"); assertCantOpenWhiteboard(joesClient, whiteboardId); assertCantOpenWhiteboard(joesClient, whiteboardId, "wildguess"); joesClient.openProtectedWhiteboard(whiteboardId, "bigsecret"); assertTrue(joesClient.hasWhiteboard()); }

मेरा लक्ष्य स्वीकृति परीक्षण को इतना छोटा, स्वच्छ और पठनीय बनाना है कि टिप्पणियां निरर्थक हो जाएं। प्रारंभिक छद्म कोड और टिप्पणियां केवल एक टेम्पलेट के रूप में काम करती हैं - "यह है कि कोड कितना साफ होना चाहिए!" टिप्पणियों को हटाने से जीत की भावना मिलती है, और एक बोनस के रूप में विधि और भी कम हो जाती है!

आगे क्या है?

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

passwordProtectionRequiresAuthentication
protectWhiteboard
passwordOwnerDoesntHaveToKnowThePassword
ChangePassword
removePassword
whiteboardPasswordCanOnlyBeChangedByThePersonWhoSetIt

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

मैनुअल परीक्षण के बारे में कैसे?

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

मुख्य बिंदु

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

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

एक बार जब आप यह कर लेते हैं, तो आपने सबसे कठिन बाधा को पार कर लिया है। आपने ATDD का उपयोग करना शुरू कर दिया!

लेखक के बारे में

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

अलेक्जेंडर एंड्रोनोव (@ alex4Zero), एंटोन बेवज़ुक (@bevzuk) और दिमित्री पावलोव द्वारा अनुवादित
स्मार्ट स्टेप ग्रुप ।

हेनरिक नाइबेरग के लेख का अनुवाद "ट्रेंच से ATDD" (उन्नत के साथ ATDD)