इकाई परीक्षण प्रतियोगिता


12

मेरे नियोक्ता एक मासिक इकाई परीक्षण दिवस प्रतियोगिता चलाते हैं। एक पूरा दिन लेखन इकाई परीक्षणों के लिए समर्पित है - जाहिर है हम पूरे महीने अधिक परीक्षण करते हैं, लेकिन यह एक पूरा दिन है - और प्रतियोगिता के "विजेता" को पुरस्कार दिया जाता है। हालांकि, हम यह निर्धारित करना मुश्किल कर रहे हैं कि विजेता कौन है।

हम प्रत्येक परीक्षण मामले के लिए अंक प्रदान कर रहे थे। तो अगर आप इस तरह एक इकाई परीक्षण लिखा था ...

for (int i = 0; i < 100; i++) {
  assertTrue(i*i, square(i));
}

आपको 100 अंक दिए जाएंगे। जाहिर है कि यह एक सरलीकृत उदाहरण है लेकिन यह प्रत्येक परीक्षण मामले को "अंक" प्रदान करने के साथ समस्याओं को प्रदर्शित करता है।

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

क्या किसी के पास कोई सुझाव है कि हम इस प्रतियोगिता के विजेता को बेहतर तरीके से कैसे निर्धारित कर सकते हैं?

संपादित करें

मुझे पता है कि इकाई परीक्षण कैसे लिखना है, मुझे पता है कि प्रभावी इकाई परीक्षण कैसे लिखना है, मुझे यह निर्धारित करने में सहायता की आवश्यकता नहीं है कि क्या परीक्षण करना है। इस प्रतियोगिता पर मेरा कोई नियंत्रण नहीं है - प्रतियोगिता आगे बढ़ेगी। इसलिए या तो मैं इसे बेहतर बनाने के लिए कुछ इनपुट जोड़ता हूं या गेमिंग टेस्ट्स को आगे बढ़ाता हूं (हां, मैं उन्हें खेलता हूं। बेशक मैं उन्हें खेलता हूं। जीतने के लिए पुरस्कार हैं)

संपादित करें

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


काफी नहीं। मैंने इसे शुरू से महसूस किया
शॉन

2
आप अभी तक पूरी तरह से काफी हद तक महसूस नहीं कर रहे हैं। सबसे अच्छा परीक्षण मामलों को लिखने वाले किसी भी उपाय में या तो पूरी तरह से व्यक्तिपरक होगा या कुछ हद तक ये समस्याएं हैं। इस प्रतियोगिताओं के लिए आपके लक्ष्य क्या हैं और कितने परिपक्व हैं (यानी, सबसे अच्छे परीक्षण लिखने की बजाय स्कोरिंग का फायदा उठाने की संभावना नहीं है) पर प्रतियोगी क्या करेंगे, इस पर निर्भर करता है।

फिर से, नहीं। मुझे एहसास हुआ कि उन्हें नामांकित किया जा सकता है। इस प्रतियोगिता पर मेरा कोई नियंत्रण नहीं है, लेकिन पूछा गया कि "हम यह कैसे बेहतर कर सकते हैं"
शॉन

13
क्या इसे एक प्रतियोगिता नहीं बनाने के लिए एक सुधार माना जाएगा? सब कुछ एक प्रतियोगिता क्यों होना है? आप सहयोग क्यों नहीं कर सकते? हो सकता है कि आपके कुछ अधिक बेकार इकाई परीक्षणों से छुटकारा पाएं और उपयोगी धुएं और प्रतिगमन परीक्षणों का एक अच्छा सूट बनाने में मदद मिलेगी।
थॉमस ओवेन्स

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

जवाबों:


15

क्या किसी के पास कोई सुझाव है कि हम इस प्रतियोगिता के विजेता को बेहतर तरीके से कैसे निर्धारित कर सकते हैं?

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

एक बोनस के रूप में, आप अपने सभी परीक्षणों की समीक्षा करेंगे।


2
यह मेरा भी विचार था। परीक्षणों के मूल्य को मापने का कोई अन्य तरीका नहीं है।
एरिक किंग

2
हां, "अच्छा परीक्षण" एक ऐसी व्यक्तिपरक चीज है जिसे न्याय करने पर विचार करने की आवश्यकता है, या तो साथियों या सम्मानित अधिकारियों द्वारा। मैट्रिक्स का पीछा करते हुए बस बहुत सारे व्यर्थ प्रयास और थोड़ा वास्तविक मूल्य प्राप्त होगा। कई पुरस्कारों के लिए दिलचस्प हो सकता है: सबसे कल्पनाशील परीक्षण, एक "परीक्षण कुछ पहले से अप्राप्य माना जाता है" पुरस्कार, सर्वश्रेष्ठ प्रदर्शन परीक्षण, सबसे प्रभावी परीक्षण, सबसे अस्पष्ट परीक्षण, सबसे चतुर परीक्षण, सबसे मूल्यवान परीक्षण, अंत उपयोगकर्ताओं की सराहना करने की सबसे अधिक संभावना है ...
दोपहर

6

तो अगर आप इस तरह एक इकाई परीक्षण लिखा था ...

for (int i = 0; i < 100; i++) {
 assertTrue(i*i, square(i));
}

आपको 100 अंक दिए जाएंगे।

मैं इस व्यक्ति को 0 अंक दूंगा (भले ही परीक्षण वास्तव में प्रासंगिक कुछ का परीक्षण कर रहा था), क्योंकि एक लूप के भीतर अभिकल्पना बहुत कम समझ में आता है और कई जोर के साथ परीक्षण (विशेष रूप से एक लूप या मानचित्र के रूप में) के साथ काम करना मुश्किल है।

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

यदि अभियोगों की संख्या अप्रासंगिक है, तो परीक्षणों की संख्या भी अप्रासंगिक है। यह कई मेट्रिक्स के लिए भी मामला है (संयुक्त वाले सहित) इस तरह की स्थितियों के लिए कोई कल्पना कर सकता है।

आदर्श रूप से, आप प्रणालीगत दृष्टिकोण लागू करेंगे। व्यवहार में, यह ज्यादातर सॉफ्टवेयर विकास कंपनियों में काम कर सकता है। इसलिए मैं कुछ अन्य बातों का सुझाव दे सकता हूं:

  1. परीक्षणों के लिए जोड़ी समीक्षाओं का उपयोग करना और कुछ प्रति मिनट मीट्रिक के डब्ल्यूटीएफ की संख्या के समान है ।

  2. बग की संख्या पर समय के साथ उन परीक्षणों के प्रभाव को मापें । इसके कई लाभ हैं:

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

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


1
शून्य अंक के लिए +1। अन्य आपत्तियाँ एएए होंगी - व्यवस्था, अधिनियम, अभिकथन; पैरामीटर परीक्षण; कार्यान्वयन के कोड की नकल नहीं ...
पैकर

5

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

इसलिए, मुझे लगता है कि यह समझ में आता है कि विजेता वह डेवलपर होना चाहिए जो सबसे अधिक बग पाता है, या डेवलपर जिसके परीक्षण कोड कवरेज में सबसे बड़ी वृद्धि प्राप्त करते हैं।

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

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

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


2
होनहार लगता है ... लेकिन फिर "द सिस्टम द गेमिंग" व्यवहार अपने आप को ज्ञात-एकमात्र कीड़े के एक अच्छे संग्रह में बदल देता है जिसे आप "अगले परीक्षण प्रतियोगिता" के लिए खोजते हैं ... dilbert.com/strip/1995-11 -13
23

3
एक विकल्प कोड में बग के लिए केवल पुरस्कार अंक है जो किसी और ने लिखा है।
सेल स्केग्स


@ col6y आप सही हैं, यह काफी महत्वपूर्ण है। दुर्भाग्य से, सिस्टम को रिग करने के अभी भी तरीके हैं। उदाहरण के लिए, यदि आपका कोड अपना काम करने के लिए मेरे कोड को आमंत्रित करता है, तो मेरा कोड यह देख सकता है कि आपका कोड "दुर्घटना" से ग्रस्त है।
माइक नाइस

3
मैं असहमत हूं। यूनिट परीक्षण, जब वे नए लिखे जाते हैं, तो पहली बार में कीड़े खोजने के लिए नहीं हैं , यह एक गिरावट है। वे लिखे जाने के हफ्तों या महीनों बाद प्रतिगमन पा सकते हैं, लेकिन प्रतियोगिता के लिए एक उपयोगी मैट्रिक्स प्रदान करने के लिए शायद बहुत देर हो चुकी है। आप आमतौर पर एक विशिष्ट बग के बाद एक इकाई परीक्षण लिखते हैं, यह सुनिश्चित करने के लिए कि आपको भविष्य में बाद में उसी प्रकार का बग नहीं मिलेगा।
डॉक ब्राउन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.