परीक्षण कोड

Question

की तुलना में यूनिट परीक्षणों का विशिष्ट आकार मैं उत्सुक हूं कि लोग टीडीडी कर रहे समय परीक्षण कोड के उत्पादन कोड के अनुपात के लिए उचित/सामान्य मूल्य क्या है। एक घटक को देखते हुए, मेरे पास उत्पादन कोड की 130 लाइनों के लिए टेस्ट कोड की 530 लाइनें हैं। उत्पादन कोड की 360 लाइनों के लिए एक अन्य घटक में टेस्ट कोड की 1000 लाइनें हैं। इसलिए यूनिट परीक्षणों को लगभग 3x से 5x जितना अधिक कोड की आवश्यकता होती है। यह जावास्क्रिप्ट कोड के लिए है। मेरे पास अधिक परीक्षण सी # कोड आसान नहीं है, लेकिन मुझे लगता है कि एक और प्रोजेक्ट के लिए मैं 2x से 3x जितना टेस्ट कोड और फिर उत्पादन कोड देख रहा था।

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

मुझे पता है कि कोड की रेखाएं एक ढीली मीट्रिक है, लेकिन चूंकि मैं परीक्षण और उत्पादन (समान दूरी प्रारूप, टिप्पणियों की एक ही राशि, आदि) दोनों के लिए एक ही शैली में कोड करता हूं, मान तुलनीय हैं।

Answer 1

यह वास्तव में इस बात पर निर्भर करेगा कि चीजें कितनी अच्छी तरह से फैली हुई हैं, लेकिन मेरे अनुभव के लिए (हाँ, मैंने इसे कुछ परियोजनाओं पर माप लिया है), मैंने अनुपात 2: 1 से 5: 1 तक देखा है (यह परीक्षण कोड के लिए है बेशक)। सी 2 विकी पर ProductionCodeVsUnitTestsRatio और UnitTestToCodeRatio पृष्ठों पर भी एक नज़र डालें।

Answer 2

ये संख्या सामान्य लगती है। मैंने लिखा सबसे लंबा यूनिट परीक्षण 1500 से अधिक लाइनों था और यह केवल कोड की 300 लाइनों का परीक्षण करता था।

Answer 3

वाह, ये संख्या काफी बड़ी हैं! मैं मोटे तौर पर 1: 1 हूं, कभी-कभी कक्षाओं के लिए जिनकी उच्च चक्रवात जटिलता होती है, यह इकाई परीक्षण एलओसी के पक्ष में करीब 2: 1 हो सकती है, लेकिन तब अलार्म घंटी को सेट करता है जिसे कक्षा को रिफैक्टरिंग की आवश्यकता होती है।

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

क्या आप अपने परीक्षणों का पुन: उपयोग कर रहे हैं? सेटअप आदि के किसी भी नकल को अलग तरीकों से ले जा रहे हैं?

क्या आप अपने यूनिट परीक्षणों को सरल रखते हैं ताकि वे केवल प्रति परीक्षण एक चीज़ पर जोर दे सकें?

और क्या आप गेटर्स/सेटर्स जैसी चीजों का अत्यधिक परीक्षण कर रहे हैं?

Answer 4

विभिन्न भाषाओं और परीक्षण ढांचे बहुत अलग होंगे। उदाहरण के लिए, बीडीडी testUnit शैली कोड से अधिक "DRYer" ढांचे। साथ ही, कुछ परियोजनाओं पर मैंने जावा के कुछ ही पंक्तियों के माध्यम से बहुत बड़े डेटा सेट को खिलाया - जिसने कोड की हजारों लाइनों का परीक्षण किया - इसलिए मेरा अनुपात सभी खराब हो जाएगा।

मैंने अभी अपनी तीन सबसे हाल की परियोजनाओं (मध्यम आकार की रेल) ​​को देखा, और अनुपात का परीक्षण करने के लिए कोड 1: 2.3, 1: 1.6, और 1: 1.9 था ... इसलिए आप समान हैं जैसे वे समान हैं। (मैं सिर्फ rake stats भाग गया - मैं वास्तव में कभी नहीं से पहले उन्हें देखा।)

वैसे भी, लक्षण यदि आप बहुत अधिक परीक्षण है कि चेतावनी:

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

Answer 5

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