आपको ऐसी सर्विस मिली है जिसमें कोई टेस्ट नहीं है और आपको उसका core logic बदलना है। आप इसे कैसे संभालेंगे?

बदलने से पहले मौजूदा व्यवहार को बांध दीजिए। किसी स्थिर सीमा पर characterization tests लिखिए, असली inputs देकर वही assert कीजिए जो कोड आज करता है, बग समेत, ताकि आपके पास बदलाव पकड़ने वाला जाल हो। फिर उन टेस्ट को हरा रखते हुए छोटे छोटे कदमों में refactor कीजिए, और जिस लॉजिक को छूना है उसे टेस्ट होने लायक चीज में निकाल लीजिए। जब वह जोड़ बन जाए तभी व्यवहार बदलिए, और हर बदलाव के साथ अपना टेस्ट आए।

जिस लॉजिक की मैं जांच नहीं कर सकता उसे मैं बदलता नहीं, तो पहला कदम जाल है। मैं सबसे ऊंची स्थिर सीमा पर characterization tests लिखता हूं, आम तौर पर HTTP handler या किसी service entry point पर, और वही assert करता हूं जो कोड अभी कर रहा है, उन चीजों समेत जिन पर मुझे बग का शक है। मकसद correctness नहीं, बदलाव पकड़ना है। अगर मेरे पास प्रोडक्शन का एक्सेस है तो मैं कुछ सौ असली request और response जोड़े पकड़ लेता हूं, क्योंकि हाथ से बनाए गए inputs अजीब मामलों को छोड़ देते हैं और तोड़ते वही अजीब मामले हैं। फिर मैं टेस्ट पूरे रास्ते हरे रखते हुए छोटे कदमों में refactor करता हूं, और जिस लॉजिक को सच में छूना है उसे ऐसे फंक्शन में खींच लाता हूं जिसे मैं सीधे बुला सकूं। तभी मैं व्यवहार बदलता हूं, और हर बदलाव के साथ एक असली टेस्ट आता है और यह फैसला भी कि पुराना व्यवहार जानबूझकर था या नहीं। एक पुरानी pricing सर्विस में मैंने ठीक यही किया और पकड़े गए ट्रैफिक ने दो rounding रास्ते उजागर कर दिए जो आपस में मेल नहीं खाते थे, जिनके बारे में किसी को पता ही नहीं था। ऐसी चीजें जाल के साथ मिलती हैं और उसके बिना खत्म हो जाती हैं।