सामान्य रूप से परीक्षण कोड आसान नहीं है। यदि ऐसा होता, तो हम यह सब बहुत पहले कर रहे थे, और केवल पिछले 10-15 वर्षों में इस तरह का कोई सौदा नहीं कर रहे थे। सबसे बड़ी कठिनाइयों में से एक हमेशा यह निर्धारित करने में रही है कि कोड को कैसे कूटबद्ध किया गया है, जो बिना संक्षिप्त रूप से लिखे, और अच्छी तरह से फैक्टेड, और अतिक्रमण को तोड़ने के बिना परीक्षण करने योग्य है। BDD प्रिंसिपल का सुझाव है कि हम लगभग पूरी तरह से व्यवहार पर ध्यान केंद्रित करते हैं, और कुछ मायनों में यह सुझाव देते हैं कि आपको वास्तव में इतनी बड़ी डिग्री के लिए आंतरिक विवरणों के बारे में चिंता करने की आवश्यकता नहीं है, लेकिन यह अक्सर चीजों को परीक्षण करने में काफी कठिन बना सकता है। बहुत सारे निजी तरीके जो बहुत ही छिपे हुए तरीके से "सामान" करते हैं, क्योंकि यह अधिक सार्वजनिक स्तर पर सभी संभावित परिणामों से निपटने के लिए आपके परीक्षण की समग्र जटिलता को बढ़ा सकता है।
मॉकिंग कुछ हद तक मदद कर सकता है, लेकिन फिर से काफी बाहरी रूप से केंद्रित है। डिपेंडेंसी इंजेक्शन भी काफी अच्छी तरह से काम कर सकता है, फिर से मॉक या टेस्ट डबल्स के साथ, लेकिन इसके लिए यह भी आवश्यक हो सकता है कि आप तत्वों को या तो इंटरफ़ेस के माध्यम से, या सीधे, कि आप अन्यथा छिपे रहना पसंद कर सकते हैं - यह विशेष रूप से सच है यदि आप चाहें तो आपके सिस्टम के भीतर कुछ वर्गों के बारे में सुरक्षा का अच्छा स्तर है।
मेरे लिए, जूरी अभी भी बाहर है कि क्या आपकी कक्षाओं को अधिक आसानी से परीक्षण योग्य बनाया जा सकता है। यह समस्याएं पैदा कर सकता है यदि आप विरासत कोड को बनाए रखते हुए नए परीक्षण प्रदान करने की आवश्यकता महसूस करते हैं। मैं स्वीकार करता हूं कि आपको एक सिस्टम में पूरी तरह से सब कुछ परीक्षण करने में सक्षम होना चाहिए, फिर भी मुझे अप्रत्यक्ष रूप से - यहां तक कि एक वर्ग के निजी प्रशिक्षकों को भी उजागर करने का विचार पसंद नहीं है, ताकि मैं उनके लिए एक परीक्षण लिख सकूं।
मेरे लिए, समाधान हमेशा काफी व्यावहारिक दृष्टिकोण लेने के लिए रहा है, और प्रत्येक विशिष्ट स्थिति के अनुरूप कई तकनीकों को संयोजित किया है। मैं अपने परीक्षणों के लिए आंतरिक गुणों और व्यवहारों को उजागर करने के लिए विरासत में प्राप्त परीक्षण डबल्स का उपयोग करता हूं। मैं उन सभी चीजों का मजाक उड़ाता हूं जो मेरी कक्षाओं से जुड़ी हो सकती हैं, और जहां यह मेरी कक्षाओं की सुरक्षा से समझौता नहीं करेगी, मैं परीक्षण के उद्देश्यों के लिए व्यवहार को ओवरराइड या इंजेक्ट करने का साधन प्रदान करूंगा। मैं और भी अधिक कार्यक्रम संचालित इंटरफ़ेस प्रदान करने पर विचार करूंगा, अगर यह कोड का परीक्षण करने की क्षमता में सुधार करने में मदद करेगा
जहां मुझे कोई भी "अप्रतिबंधित" कोड मिलता है, मैं देखता हूं कि क्या मैं चीजों को अधिक परीक्षण योग्य बनाने के लिए रिफ्लेक्टर कर सकता हूं। जहाँ आपके पास बहुत सारे निजी कोड होते हैं जो पर्दे के सामान के पीछे छिपे होते हैं, अक्सर आपको नई कक्षाएं मिलेंगी जो टूटने की प्रतीक्षा कर रही हैं। इन वर्गों को आंतरिक रूप से इस्तेमाल किया जा सकता है, लेकिन अक्सर कम निजी व्यवहार के साथ स्वतंत्र रूप से परीक्षण किया जा सकता है, और अक्सर बाद में पहुंच और जटिलता की कम परतें। हालांकि मैं इससे बचने के लिए ध्यान रखता हूं कि इसमें निर्मित टेस्ट कोड के साथ उत्पादन कोड लिख रहा है। यह " टेस्ट लग्स " बनाने के लिए आकर्षक हो सकता है if testing then ..., जिसके परिणामस्वरूप ऐसी भयावहता शामिल है , जो एक परीक्षण समस्या को पूरी तरह से विघटित और अपूर्ण हल नहीं होने का संकेत देती है।
आपको गेरार्ड मेस्ज़्रोस की एक्सयूनिट टेस्ट पैटर्न बुक पढ़ने में मदद मिल सकती है , जो इस तरह के सभी सामानों को बहुत अधिक विस्तार से कवर करता है, जितना कि मैं यहाँ जा सकता हूँ। मैं शायद वह सब कुछ नहीं करता जो वह सुझाता है, लेकिन इससे निपटने के लिए कुछ पेचीदा परीक्षण स्थितियों को स्पष्ट करने में मदद करता है। दिन के अंत में, आप अपने पसंदीदा डिज़ाइनों को लागू करते समय अपनी परीक्षण आवश्यकताओं को पूरा करने में सक्षम होना चाहते हैं, और यह तय करने के लिए बेहतर विकल्पों की सभी को बेहतर ढंग से समझने में मदद करता है कि आपको कहां समझौता करने की आवश्यकता हो सकती है।