मेरे पास कई जुनीट परीक्षण मामले हैं जिन्हें वर्तमान में जावाडोक टिप्पणियों के साथ दस्तावेज नहीं किया गया है।क्या जुनीट परीक्षणों को जवाडोक किया जाना चाहिए?
मेरा बाकी कोड दस्तावेज है, लेकिन मुझे आश्चर्य है कि यह इन परीक्षणों को दस्तावेज करने के प्रयास के लायक भी है।
यदि परीक्षण का उद्देश्य स्पष्ट है, तो मैं इसे दस्तावेज करने से परेशान नहीं करता हूं।
यदि यह स्पष्ट नहीं है क्योंकि यह कुछ अस्पष्ट स्थिति से संबंधित है - या यदि मैं एक विशिष्ट बग का संदर्भ देना चाहता हूं, उदाहरण के लिए - में केस मैं दस्तावेज़ जोड़ दूंगा। मैं अपवाद फेंक आदि दस्तावेज दस्तावेज नहीं है - बस विधि का एक त्वरित सारांश। यह अपेक्षाकृत कम ही होता है। मैं कई परीक्षणों के भीतर उपयोग की जाने वाली सहायक विधियों के लिए दस्तावेज़ जोड़ने की अधिक संभावना रखता हूं।
मुझे परीक्षण मामलों में जावडोकिंग में कोई मूल्य नहीं मिला है। मैं सिर्फ परीक्षण के उद्देश्य को जानने के लिए विधि नाम वर्णनात्मक बना देता हूं।
रूबी में, मुझे पता है कि परीक्षण के नाम से दस्तावेज़ बनाने के लिए उपकरण हैं, लेकिन मैंने जावा में इनमें से कोई एक नहीं देखा है।
चाहे जावाडॉक या नहीं, मुझे लगता है कि यूनिट परीक्षण निश्चित रूप से दस्तावेज किए जाने चाहिए। ऐसे मामलों में जहां कोई औपचारिक विनिर्देश मौजूद नहीं है, यूनिट परीक्षण कोड के अपेक्षित व्यवहार को परिभाषित करने के लिए निकटतम आता है। परीक्षण के मामलों को दस्तावेज करके, आप पाठक को यह स्पष्ट कर देंगे कि परीक्षण क्या परीक्षण कर रहा है, और यह इसका परीक्षण क्यों कर रहा है।
पूरी तरह से आपसे सहमत हैं। मैं भी ऐसा ही करता हूं। मैं विधि के रूप में विधि का उपयोग करता हूं [MethodUnderTest] _Should [अपेक्षित व्यवहार] _ जब [परिदृश्य]। तो यह दस्तावेज के रूप में कार्य करता है। इसके अलावा मैं javadoc व्यवहार जो उत्पाद प्रलेखन में शामिल किया जाना चाहिए। –
मुझे लगता है कि परीक्षणों के तहत जवाडोक के लिए मूल्यवान है।
दस्तावेज़ीकरण के रूप में परीक्षणों के बारे में सोचते समय, यह "दस्तावेज़ीकरण दस्तावेज" को अधिक समझ में नहीं आता है। प्रत्येक परीक्षण का नाम पहले से ही वर्णन कर सकता है कि परीक्षण का उद्देश्य क्या है - उस परीक्षण द्वारा निर्दिष्ट व्यवहार क्या है।
परीक्षणों के लिए लंबे, वर्णनात्मक नामों का उपयोग करें, और परीक्षण कोड को यथासंभव पठनीय रखें।
उदाहरण के लिए परीक्षण मामलों in this project पर एक नज़र डालें। क्या उनमें से कोई ऐसा कुछ करता है जो परीक्षण और परीक्षण कोड के नाम को देखकर स्पष्ट रूप से स्पष्ट नहीं है?
यह केवल कुछ दुर्लभ मामलों में है, जब परीक्षण कोड अस्पष्ट है, परीक्षणों में टिप्पणियों की आवश्यकता होती है। उदाहरण के लिए, यदि आप बहु-थ्रेडेड कोड का परीक्षण कर रहे हैं और टेस्ट कोड यह सुनिश्चित करने के लिए अजीब चीजें करता है कि परीक्षण कोड सही क्रम में चलता है। लेकिन क्लीनर टेस्ट कोड लिखने के लिए उन मामलों में भी a comment is an apology।
नरक हाँ। यहां तक कि अगर यह सिर्फ ...
आदेश बनाएं, ऑर्डर करें, सहेजें, लोड करें & इसे जांचें।
यदि यह वास्तव में एक सरल परीक्षण है, तो शायद नहीं।
मुझे लगता है कि कोड में परिवर्तन के रूप में, कभी-कभी परीक्षण का कारण स्पष्ट नहीं होता है क्योंकि यह एक बार था।
हो सकता है कि आप किसी ऐसे व्यक्ति को प्राप्त कर सकें जो आपके कोड से पूरी तरह परिचित नहीं है ताकि आपको कुछ त्वरित प्रतिक्रिया दे सके कि आपके परीक्षण आसानी से समझ गए हैं या नहीं।
जिस कंपनी के लिए मैं काम करता हूं, हम अपने परीक्षणों को वर्णनात्मक नाम और दस्तावेज़ जटिलता देने का प्रयास करते हैं, लेकिन पहले ड्राफ्ट के साथ यह "सही" प्राप्त करना मुश्किल होता है क्योंकि डेवलपर के लिए स्पष्ट चीजें हमेशा स्पष्ट नहीं होती हैं दूसरों के लिए।
टेस्ट कोड की तरह व्यवहार किए जाते हैं और एक पीयर समीक्षा प्रक्रिया के हिस्से के रूप में सबमिट किए जाते हैं, इसलिए हमारी (छोटी) टीम इस बात पर टिप्पणी कर सकती है कि कोई परीक्षण आसानी से समझा जाता है या नहीं।
यदि कोई परीक्षण थोड़ा उलझन में है, तो हम तदनुसार नाम या दस्तावेज अपडेट कर सकते हैं और हम क्या काम करते हैं और क्या नहीं करते हैं इसके बेहतर गेज के साथ आते हैं।
क्या यह सुझाव देने के लिए पाखंडी है कि कोड टिप्पणियां एक विरोधी पैटर्न हैं? मैं उपरोक्त उत्तरों से सहमत हूं, आदर्श रूप से आपका कोड बिना किसी टिप्पणी के भरोसा करने के लिए वर्णनात्मक होगा। यह विशेष रूप से सच है यदि आप एक (एंटरप्राइज़) वातावरण में हैं जहां लोग टिप्पणी अपडेट किए बिना कोड अपडेट करना चाहते हैं तो टिप्पणियां भ्रामक हो जाती हैं।
मैं आपसे सहमत हूं। मुझे यूनिट परीक्षण देखने से नफरत है जो स्पष्ट नहीं हैं कि वे क्या परीक्षण कर रहे हैं। कोड समय के साथ बदलता है, और मूल कारण स्पष्ट से कम हो सकता है। –
मैं प्रत्येक assertFoo कथन में एक स्पष्टीकरण स्ट्रिंग देखना चाहता हूं। –