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