2010-08-23 23 views
5

मुझे पता है कि यह प्रश्न उन लोगों के समान ही है जो पहले पोस्ट किए गए हैं लेकिन मैं इस विषय पर उचित तरीके से चर्चा करना चाहता हूं।तर्क अपवाद यूनिट परीक्षण किया जाना चाहिए?

क्या आपको लगता है कि "स्पष्ट" अपवाद इकाई परीक्षण किया जाना चाहिए?

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

दूसरे शब्दों में मैं उन अपवादों की बात कर रहा हूं जिन्हें कक्षा अनुबंध के सबसे सरल भाग के उल्लंघन के बाद फेंक दिया जाना चाहिए।

आपकी राय के लिए धन्यवाद।

उत्तर

1

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

8

बिल्कुल। आप उन्हें "स्पष्ट" कहते हैं, लेकिन पूर्व-स्थितियों को सत्यापित करने के बारे में याद रखने के बारे में कुछ भी स्पष्ट नहीं है। असल में, मेरे करियर में मैंने जो कोड देखा है, वह बाद में तबाही को रोकने के लिए यह स्पष्ट कदम नहीं उठाता है।

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

और चलो उचित हो ... किसी भी मौके पर मुझे एक और परीक्षा लिखनी है और हरी बार देखें, मैं खुश हूं। :)

0

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

एकमात्र बार जब मैं गेटर्स और सेटर्स का परीक्षण नहीं करता हूं तो यह है कि वे केवल सरल असाइनमेंट या मूल्य लौटा रहे हैं।

3

जिसका मुख्य कारण

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