सबसे पहले, यूनिट परीक्षण पर युक्तियों के साथ यहां एक शानदार लेख
है । दूसरा, मुझे पुराने कोड में कई बदलाव करने से बचने का एक
शानदार तरीका मिल गया है, जब तक कि आप इसका परीक्षण नहीं कर लेते, इसे
थोड़ा सा रिफैक्टर करें। ऐसा करने का एक आसान तरीका निजी सदस्यों को
सुरक्षित बनाना है, और फिर संरक्षित क्षेत्र को ओवरराइड करना है।
उदाहरण के लिए, मान लीजिए कि आपके पास एक कक्षा है जो कन्स्ट्रक्टर
के दौरान डेटाबेस से कुछ सामान लोड करती है। इस मामले में, आप केवल एक
संरक्षित विधि को ओवरराइड नहीं कर सकते हैं, लेकिन आप डीबी तर्क को
संरक्षित क्षेत्र में निकाल सकते हैं और फिर परीक्षण में इसे ओवरराइड
कर सकते हैं।
public class MyClass {
public MyClass() {
// undesirable DB logic
}
}
हो जाता है
public class MyClass {
public MyClass() {
loadFromDB();
}
protected void loadFromDB() {
// undesirable DB logic
}
}
और फिर आपका परीक्षण ऐसा कुछ दिखता है:
public class MyClassTest {
public void testSomething() {
MyClass myClass = new MyClassWrapper();
// test it
}
private static class MyClassWrapper extends MyClass {
@Override
protected void loadFromDB() {
// some mock logic
}
}
}
यह कुछ हद तक खराब उदाहरण है, क्योंकि आप इस मामले में डीबीयूनीट
का उपयोग कर सकते हैं, लेकिन मैंने वास्तव में हाल ही में इसी तरह के
मामले में ऐसा किया क्योंकि मैं लोड होने वाले डेटा से पूरी तरह से
असंबंधित कुछ कार्यक्षमता का परीक्षण करना चाहता था, इसलिए यह बहुत
प्रभावी था। मुझे अन्य समान मामलों में सदस्यों के इस तरह के उजागर
होने का भी पता चला है, जहां मुझे लंबे समय तक कक्षा में रहने वाली
कुछ निर्भरता से छुटकारा पाना होगा।
यदि आप एक ढांचा लिख रहे हैं, तो मैं इस समाधान के खिलाफ अनुशंसा
करता हूं, जब तक कि आप वास्तव में सदस्यों को अपने ढांचे के
उपयोगकर्ताओं को उजागर नहीं करते।
यह एक हैक का थोड़ा सा है, लेकिन मुझे यह काफी उपयोगी पाया है।