सबसे पहले, here's a great article with tips on unit testing। दूसरा, मुझे पुराने कोड में कई बदलाव करने से बचने का एक शानदार तरीका मिल गया है, जब तक कि आप इसका परीक्षण नहीं कर लेते, इसे थोड़ा सा रिफैक्टर करें। ऐसा करने का एक आसान तरीका निजी सदस्यों को सुरक्षित बनाना है, और फिर संरक्षित क्षेत्र को ओवरराइड करना है।
उदाहरण के लिए, मान लें कि आपके पास एक कक्षा है जो कन्स्ट्रक्टर के दौरान डेटाबेस से कुछ सामान लोड करती है। इस मामले में, आप केवल एक संरक्षित विधि को ओवरराइड नहीं कर सकते हैं, लेकिन आप डीबी तर्क को संरक्षित क्षेत्र में निकाल सकते हैं और फिर परीक्षण में इसे ओवरराइड कर सकते हैं।
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
}
}
}
यह एक बुरा उदाहरण के लिए कुछ हद तक है, क्योंकि आप इस मामले में DBUnit इस्तेमाल कर सकते हैं, लेकिन मैं वास्तव में हाल ही में इसी तरह के मामले में ऐसा किया क्योंकि मैं लोड होने वाले डेटा से पूरी तरह से असंबंधित कुछ कार्यक्षमता का परीक्षण करना चाहता था, इसलिए यह बहुत प्रभावी था। मुझे अन्य समान मामलों में सदस्यों के इस तरह के उजागर होने का भी पता चला है, जहां मुझे लंबे समय तक कक्षा में रहने वाली कुछ निर्भरता से छुटकारा पाना होगा।
यदि आप एक ढांचा लिख रहे हैं, तो मैं इस समाधान के खिलाफ अनुशंसा करता हूं, जब तक कि आप वास्तव में सदस्यों को अपने ढांचे के उपयोगकर्ताओं को उजागर नहीं करते।
यह एक हैक का थोड़ा सा है, लेकिन मुझे यह काफी उपयोगी पाया गया है।
स्रोत
2008-08-10 19:22:36