विरासत कोड के साथ महत्वपूर्ण समस्या यह है कि इसका कोई परीक्षण नहीं है। तो आपको कुछ (और फिर और ...) जोड़ने की आवश्यकता है।
@Mattnz ने कहा कि यह अपने आप में बहुत काम लेगा। लेकिन विरासत कोड की विशेष समस्या यह है कि इसे कभी भी परीक्षण योग्य नहीं बनाया गया था । इसलिए आमतौर पर यह स्पेगेटी कोड की एक बड़ी जटिल गड़बड़ है, जहां छोटे भागों को इकाई परीक्षण के लिए अलग करना बहुत मुश्किल या बिल्कुल असंभव है। इसलिए यूनिट परीक्षण से पहले, आपको इसे और अधिक परीक्षण योग्य बनाने के लिए कोड को रीफैक्टर करने की आवश्यकता है ।
हालाँकि, सुरक्षित रूप से रिफ्लेक्टर करने के लिए, आपके पास यह सत्यापित करने के लिए इकाई परीक्षण होना चाहिए कि आपने अपने परिवर्तनों के साथ कुछ नहीं तोड़ा है ... यह विरासत कोड का कैच 22 है।
पुस्तक आपको सिखाती है कि पहली इकाई परीक्षणों को सक्षम करने के लिए कोड में पूर्ण न्यूनतम, सबसे सुरक्षित बदलाव करके इस कैच को कैसे खत्म किया जाए। ये डिज़ाइन को अच्छा बनाने के लिए नहीं हैं - केवल यूनिट परीक्षणों को सक्षम करने के लिए। वास्तव में, कभी-कभी वे डिजाइन को बदसूरत या अधिक जटिल बनाते हैं। हालांकि, वे आपको परीक्षण लिखने की अनुमति देते हैं - और एक बार आपके पास इकाई परीक्षण होने के बाद, आप डिज़ाइन को बेहतर बनाने के लिए स्वतंत्र हैं।
कोड को परीक्षण योग्य बनाने के लिए बहुत सारी तरकीबें हैं - कुछ स्पष्ट हैं, कुछ बिल्कुल नहीं हैं। ऐसी विधियाँ हैं जिनके बारे में मैंने कभी किताब पढ़े बिना अपने बारे में नहीं सोचा होगा। लेकिन जो और भी महत्वपूर्ण है वह यह है कि पंख बताते हैं कि क्या वास्तव में एक कोड इकाई को परीक्षण योग्य बनाता है। आपको निर्भरता में कटौती करने और अपने कोड में बाधाओं को लागू करने की आवश्यकता है, लेकिन दो अलग-अलग कारणों से:
- संवेदन - कोड के एक टुकड़े को निष्पादित करने के प्रभावों की जांच करने और सत्यापित करने के लिए, और
- पृथक्करण - सबसे पहले कोड के विशिष्ट टुकड़े को एक परीक्षण दोहन में लाने के लिए।
सुरक्षित रूप से काटना निर्भरता मुश्किल हो सकता है। परिचय इंटरफेस, मॉक और डिपेंडेंसी इंजेक्शन एक लक्ष्य के रूप में साफ और अच्छा है, बस जरूरी नहीं कि इस बिंदु पर करना सुरक्षित हो। इसलिए कभी-कभी हमें किसी विधि को ओवरराइड करने के लिए परीक्षण के तहत वर्ग को उपवर्ग में करने का सहारा लेना पड़ता है जो आमतौर पर एक DB के लिए एक सीधा अनुरोध शुरू करता है। अन्य बार, हमें परीक्षण वातावरण में एक निर्भरता वर्ग / जार को एक नकली के साथ बदलने की आवश्यकता हो सकती है ...
मेरे लिए, पंख द्वारा लाई गई सबसे महत्वपूर्ण अवधारणा सीम है । सीम कोड में एक जगह है जहां आप अपने प्रोग्राम के व्यवहार को कोड को संशोधित किए बिना बदल सकते हैं । आपके कोड में सीम का निर्माण परीक्षण के तहत कोड के टुकड़े को अलग करने में सक्षम बनाता है , लेकिन यह आपको परीक्षण के तहत कोड के व्यवहार को भी महसूस करने में सक्षम बनाता है , भले ही यह सीधे करना मुश्किल या असंभव हो (जैसे क्योंकि कॉल किसी अन्य ऑब्जेक्ट या सबसिस्टम में परिवर्तन करता है। , जिसका राज्य परीक्षण विधि से सीधे क्वेरी करना संभव नहीं है)।
यह ज्ञान आपको कोड के सबसे नास्तिक ढेर में परीक्षण क्षमता के बीज को नोटिस करने की अनुमति देता है, और वहां पहुंचने के लिए न्यूनतम, कम से कम विघटनकारी, सबसे सुरक्षित परिवर्तन ढूंढता है। दूसरे शब्दों में, "स्पष्ट" रिफ्लेक्टरिंग करने से बचने के लिए, जो आपके बिना कोड को तोड़ने का जोखिम रखते हैं - क्योंकि आपके पास अभी तक इसका पता लगाने के लिए यूनिट परीक्षण नहीं हैं।