2009-12-28 11 views
5

इसके लायक ऐसे सरल कोड के लिए इकाई परीक्षण लिखने के लिए है:आदिम इकाई-परीक्षण

public class TableController { 
    private TableView view; 

    public TableController(TableView view) { 
    this.view = view; 
    } 

    public void onShowTable() { 
    view.showTable(); 
    } 
} 

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

public class TableControllerTest { 
    @Test 
    public void showTable() { 
    TableView view = createMock(TableView.class); 
    view.showTable(); 

    replayAll(); 

    TableController controller = new TableController(view); 
    controller.onShowTable(); 

    verifyAll(); 
    } 
} 

इस तरह के परीक्षण कर रहे हैं वास्तव में जरूरत है?

धन्यवाद!

+0

आप यहां देख सकते हैं: http://stackoverflow.com/questions/1968014/level-of-detail-of-your-unit-tests –

उत्तर

5

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

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

1

अलग-अलग लोगों के पास अलग-अलग राय होंगी। आपको निश्चित रूप से सब कुछ जांचने की ज़रूरत है जो गलत हो सकती है। आपके लिए इसका मतलब क्या है आप पर निर्भर करता है। अत्यधिक परीक्षण उत्पादकता को धीमा कर सकता है जैसे कि बहुत कम परीक्षण समस्याओं को याद कर सकता है। आपको यह निर्धारित करने की ज़रूरत है कि आपके लिए क्या काम करता है।

2

जब आप अपनी विधि के कार्यान्वयन को बदलते हैं तो उन्हें इसकी आवश्यकता होती है और यह सुनिश्चित करने की आवश्यकता होती है कि यह अभी भी काम करता है। और जब यह 2 साल बाद होता है, तो याद रखने की कोशिश करने में बहुत देर हो चुकी है कि यूनिट टेस्ट लिखने के लिए विधि कैसे काम करती है - आपको इसे अभी करना चाहिए।

जब आप उन्हें अधिक जटिल तरीकों/तर्क पर परीक्षण करने के लिए तुलना करते हैं तो उन्हें कम आवश्यकता होती है, लेकिन फिर भी इसकी आवश्यकता होती है।

0

टेस्ट हमेशा अच्छी बात होती है, खासकर यदि आप समय के साथ अपना कोड बढ़ने की उम्मीद करते हैं। यह जांचने में सक्षम होना उपयोगी है कि क्या आप पुराने कोड कार्यक्षमता को ठीक कर रहे हैं या फिर आपके कोड बेस में बड़े बदलाव कर सकते हैं।

हालांकि, आपके विशिष्ट मामले में, मुझे लगता है कि showTable आदि का परीक्षण करने वाले परीक्षणों और परीक्षणों से लाभ उठाने के लिए कोड के इन बिट्स की कार्यक्षमता बहुत छोटी है।

0

मैं सरल प्रतिनिधि विधियों का परीक्षण नहीं करता।

वहाँ अच्छा कहावत (हालांकि मुझे याद नहीं यह कौन से आ रहा था) है: "कभी परीक्षण सामान जो तोड़ने के लिए ... बहुत आसान है" अपनी परियोजनाओं जो नियंत्रकों को जोड़ता में

+1

आप कैसे जानते हैं कि तोड़ने के लिए बहुत आसान है? असली मानदंड भाषा सुविधाओं या बाहरी पुस्तकालयों का परीक्षण नहीं कर रहा है; जैसे आपको यह जांचने की आवश्यकता नहीं है कि 'var = 5' उस चर के लिए 5 असाइन करता है (भाषा इसकी गारंटी देता है), लेकिन आपको उस असाइनमेंट के कारण आपके कोड उत्पन्न होने वाले किसी भी दुष्प्रभाव का परीक्षण करने की आवश्यकता है। –

1

कोड, विचार , सेवाएं, रिमोट सेवाएं इत्यादि।

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

8

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

तो अंत में, मैं सरल मॉड्यूल के लिए भी परीक्षण लिखूंगा क्योंकि वे लिखने में आसान हैं, और जब मॉड्यूल अधिक जटिल हो जाते हैं तो वे प्लेसहोल्डर के रूप में कार्य करते हैं।

संबंधित मुद्दे