2012-05-12 20 views
6

मैं TDD के बुनियादी सिद्धांतों से परिचित हूँ, किया जा रहा है:यूनिट परीक्षण के लिए सबसे अच्छा तरीका क्या है जब आपके पास डमी और वास्तविक कार्यान्वयन दोनों के साथ इंटरफेस है?

  1. लिखें परीक्षण, इन कोई कार्यान्वयन
  2. परीक्षण पास करने के लिए बुनियादी कार्यान्वयन लिखें की वजह से असफल हो जायेगी
  3. Refactor कोड

हालांकि, मैं थोड़ा उलझन में हूं जहां इंटरफेस और कार्यान्वयन फिट है। मैं अपने खाली समय में एक स्प्रिंग वेब एप्लिकेशन बना रहा हूं, और बंदूकें चमकने के बजाए, मैं समझना चाहता हूं कि मैं इंटरफेस/कार्यान्वयन का थोड़ा बेहतर परीक्षण कैसे कर सकता हूं, मैंने यह सरल उदाहरण कोड यहां बनाया है:

public class RunMe 
{ 

    public static void main(String[] args) 
    { 
     // Using a dummy service now, but would have a real implementation later (fetch from DB etc.) 
     UserService userService = new DummyUserService(); 
     System.out.println(userService.getUserById(1)); 
    } 
} 

interface UserService 
{ 
    public String getUserById(Integer id); 
} 

class DummyUserService implements UserService 
{ 
    @Override 
    public String getUserById(Integer id) 
    { 
     return "James"; 
    } 
} 

मैं UserService इंटरफेस बनाने के बाद, अंत में इस का एक वास्तविक कार्यान्वयन है कि एक डेटाबेस क्वेरी करेगा, हालांकि आदेश आवेदन बंद जमीन प्राप्त करने के लिए मैं एक DummyUserService कार्यान्वयन प्रतिस्थापित कर दिया है कि अभी वापस आ जाएगी हो जाएगा अभी के लिए कुछ स्थिर डेटा।

प्रश्न: मैं उपर्युक्त के लिए एक परीक्षण रणनीति कैसे कार्यान्वित कर सकता हूं?

मैं एक परीक्षण वर्ग DummyUserServiceTest और परीक्षण कि जब मैं getUserById() फोन यह James वापस आ जाएंगे, कहा जाता है बना सकते हैं, बहुत सरल लगता है, तो (?) समय की बर्बादी नहीं।

इसके बाद, मैं एक टेस्ट क्लास RealUserService भी बना सकता हूं जो कि getUserById() डेटाबेस से उपयोगकर्ता नाम लौटाएगा। यह वह हिस्सा है जो मुझे थोड़ा सा भ्रमित करता है, ऐसा करने में, क्या यह अनिवार्य रूप से यूनिट परीक्षण की सीमा को ओवरस्टेट नहीं करता है और एक इंटरग्रेशन टेस्ट (डीबी पर हिट के साथ) बन जाता है?

प्रश्न (सुधार, थोड़ा): डमी/स्टब किए गए इंटरफेस का उपयोग करते समय, और वास्तविक कार्यान्वयन, कौन से हिस्सों को यूनिट परीक्षण किया जाना चाहिए, और कौन से हिस्सों को सुरक्षित रूप से छोड़ा जा सकता है?

मैं कुछ घंटे बिताए कल रात इस विषय पर Googling, और ज्यादातर सलाह दे क्या वास्तव में परीक्षण किया जाना चाहिए के स्थानों में या तो ट्यूटोरियल TDD है क्या, या कैसे JUnit उपयोग करने के लिए के उदाहरण हैं, लेकिन कुछ नहीं मिला। हालांकि यह पूरी तरह से संभव नहीं है, कि मैंने काफी कठिन खोज नहीं की थी या सही चीज़ की तलाश नहीं की थी ...

उत्तर

4

डमी कार्यान्वयन का परीक्षण न करें: उनका उत्पादन में उपयोग नहीं किया जाएगा। यह परीक्षण करने के लिए कोई वास्तविक अर्थ नहीं है।

यदि असली उपयोगकर्ता सेवा कार्यान्वयन डेटाबेस पर जाने के अलावा कुछ और नहीं करता है और उपयोगकर्ता आईडी को उसके आईडी द्वारा प्राप्त करता है, तो परीक्षण का परीक्षण करना चाहिए कि यह ऐसा करता है और यह सही तरीके से करता है। यदि आप चाहें तो इसे एकीकरण परीक्षण कहते हैं, लेकिन फिर भी यह एक परीक्षण है जिसे लिखा जाना चाहिए और स्वचालित होना चाहिए।

सामान्य रणनीति परीक्षण के एनोटेटेड विधि से @ न्यूनतम परीक्षण डेटा के साथ डेटाबेस को पॉप्युलेट करना है, और क्या आप परीक्षण विधि जांचते हैं कि डेटाबेस में मौजूद आईडी के लिए संबंधित उपयोगकर्ता नाम वापस आ गया है।

0

जेबी का जवाब एक अच्छा है, मैंने सोचा कि मैं एक और तकनीक फेंक दूंगा जिसका मैंने उपयोग किया है।

जब मूल परीक्षण विकास, पहली जगह में UserService को छोटा परेशान नहीं है। वास्तव में, आगे बढ़ें और असली चीज़ लिखें। Kent Beck's 3 rules का पालन करके आगे बढ़ें।

1) यह काम करें। 2) इसे सही बनाएं। 3) इसे तेजी से बनाएं।

आपका कोड परीक्षण है कि तब आईडी कार्यों से खोज की पुष्टि करनी होगी। जैसा कि जेबी ने कहा था, इस समय आपके परीक्षणों को एकीकरण टेस्ट माना जाएगा। एक बार वे गुजरने के बाद हमने चरण 1 सफलतापूर्वक हासिल कर लिया है। अब, डिज़ाइन को देखें। क्या यह सही है? किसी भी डिजाइन की गंध ट्विक करें और अपनी सूची से चरण 2 की जांच करें।

चरण 3 के लिए, हम इस परीक्षण में तेजी से बनाने की जरूरत है। हम सभी जानते हैं कि एकीकरण परीक्षण धीमे हैं और सभी लेनदेन प्रबंधन और डेटाबेस सेटअप के साथ त्रुटि प्रवण होती है। एक बार जब हम कोड काम करते हैं, तो मैं आमतौर पर एकीकरण परीक्षण से परेशान नहीं होता हूं। यह इस समय है जहां आप अपनी डमी सेवा शुरू कर सकते हैं, प्रभावी रूप से एक इकाई परीक्षण में अपने एकीकरण परीक्षण को बदल सकते हैं। अब जब यह डेटाबेस को किसी भी तरह से स्पर्श नहीं करता है, तो हम सूची से चरण 3 की जांच कर सकते हैं क्योंकि यह परीक्षण अब तेज़ है।

तो, यह दृष्टिकोण के साथ समस्या क्या है? खैर, कई लोग कहेंगे कि मुझे अभी भी डेटाबेस समर्थित बैक UserService के लिए एक परीक्षण की आवश्यकता है। मैं आमतौर पर अपने प्रोजेक्ट में चारों ओर एकीकरण परीक्षण नहीं रखता हूं। मेरी राय यह है कि इन प्रकार के परीक्षण धीमे, भंगुर होते हैं, और अधिकांश परियोजनाओं में खुद के लिए भुगतान करने के लिए पर्याप्त तर्क त्रुटियों को नहीं पकड़ते हैं।

आशा है कि मदद करता है!

ब्रैंडन

3

मैं पहली बार इस पुस्तक को पढ़ने के लिए आप की सिफारिश करेंगे: Growing Object-Oriented Software Guided by Tests स्टीव Freemand और नेट प्राइस से। यह टीडीडी से संबंधित आपके प्रश्न और कई अन्य लोगों का जवाब देता है।

अपने विशेष मामले में आपको अपने RealUserService को डीबी-एडाप्टर के साथ कॉन्फ़िगर करने योग्य बनाना चाहिए, जो वास्तविक डीबी क्वेरी करेगा। सेवा स्वयं सर्विसिंग होगी, न कि डेटा दृढ़ता। किताब पढ़ें, यह एक बहुत मदद मिलेगी :)