"शून्य Iteration" - सरल संपर्क-फ़ॉर्म सुविधा

Question

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

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

प्रश्न है - कैसे आप इस मामले में यह पहली एंड-टू-एंड परीक्षण दृष्टिकोण होगा? क्या आपके पास इस पहले परीक्षण में सभी संभावनाएं हैं, या शायद मैं इस पूरी तकनीक को गलत समझ रहा हूं।

किसी भी उदाहरण का स्वागत किया जाएगा।

Answer 1

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

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

Answer 2

इस यूज-केस कई परीक्षण मामलों में (हर निष्पादन की एक समर्पित संभव पथ का परीक्षण करती है) की ओर जाता है।

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

मेरा पहला परीक्षण होगा:

• खुश पथ 1 हिस्सा दृश्यपटल फार्म + नियंत्रक परत: उपयोगकर्ता गुजरता सही डेटा, नियंत्रक रूप ले और सांत्वना देने/stdout लोग इन
• खुश पथ 2 हिस्सा: Stdout पर लॉग इन करने के बजाय, चीजें डेटाबेस
• हैप्पी पथ 3 भाग: अनुवर्ती मेल उपयोगकर्ता
• प्रमाणीकरण त्रुटि प्रबंधन (उपयोगकर्ता गलत तरीके से भरता है, उदाहरण के लिए अनिवार्य फ़ील्ड याद करता है, गलत ईमेल- पैटर्न)
• ...

बाकी को भरें;) अधिक विस्तृत आवश्यकताओं पर निर्भर करता है ...

ऊपर यथासंभव सरल लागू करने के लिए याद रखें। जब सभी परीक्षण होते हैं, तो "आंतरिक गुणवत्ता" को अच्छा बनाने के लिए निर्दयतापूर्वक प्रतिक्रिया दें।