ऑटोमेटिंग यूनिट टेस्ट क्रिएशन


11

ऐसी कुछ रणनीतियाँ क्या हैं जिनका उपयोग इकाई परीक्षण मामलों के निर्माण को स्वचालित करने के लिए किया जा सकता है? कम से कम एक सभ्य परीक्षण केस कंकाल उत्पन्न करने में सक्षम होने के लिए आपको प्रत्येक वर्ग को देखने के लिए किन पहलुओं की आवश्यकता होगी?

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

मैं पीएचपी में यूनिट टेस्ट कंकाल बनाने के तरीकों में विशेष रूप से दिलचस्पी रखता हूं, जो कि उन सभी उपकरणों को प्रदान नहीं करता है जो अन्य भाषाओं में खर्च करते हैं , उदाहरण के लिए पूर्ण प्रकार की हिंटिंग


लेटेस्ट विजुअल स्टूडियो की आपको जरूरत है ...
जॉब

जवाबों:


5

आपकी रणनीति और कंकाल निर्भर करता है, गैर-तुच्छ रूप से, आप किस प्रकार के परीक्षण उत्पन्न करना चाहते हैं, आप किस प्रकार की कवरेज की तलाश कर रहे हैं और जिस भाषा / वातावरण में आप काम कर रहे हैं।

टेस्ट जनरेटर को लिखने के लिए यह काफी सीधा है, जो सी या जावा जैसी भाषाओं के लिए, कक्षा के हस्ताक्षर पढ़ता है और स्वचालित रूप से मानक कोने के मामलों के लिए परीक्षण उत्पन्न करता है (0, 2 यादृच्छिक मानों में अधिकतम, MAX_INT, MIN_INT, पूर्णांक तर्क के लिए, nullables के लिए अशक्त) , आदि...)। फिर आप उत्पन्न परीक्षण चला सकते हैं, प्रत्येक परीक्षण के लिए परिणाम रिकॉर्ड कर सकते हैं, और अप्रासंगिक वाले लोगों को हटाने के लिए मैन्युअल रूप से फ़िल्टर कर सकते हैं, परीक्षणों के लिए स्वीकार्य परिणामों को मंजूरी दे सकते हैं (ताकि वे स्वचालित रूप से उस पर से गुजर सकें), और अमान्य लोगों के रूप में चिह्नित करें जो विफल हो जाते हैं ।

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

तो, यहाँ कुछ घटक हैं जिन्हें आप देखना चाहेंगे:

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

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


5

मुझे अभी तक एक सार्थक आकार या जटिलता के आवेदन पर इसका उपयोग करने का मौका नहीं मिला है, लेकिन Google के कोडप्रो एनालिटिक्स सहित उपकरण हैं , जो जावा अनुप्रयोगों के लिए यूनिट परीक्षणों की पीढ़ी को स्वचालित करते हैं । मुझे एक वाणिज्यिक उत्पाद, पैरासॉफ्ट का सी ++ टेस्ट भी मिला , जो सी ++ यूनिट परीक्षणों की पीढ़ी के लिए अनुमति देता है

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

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


बस कुछ और प्रचार प्रदान करने के लिए, फाल्कन ने एक परियोजना पर कोडप्रो की कोशिश की और अपने अनुभवों के बारे में थोड़ा धुंधला लिखा


Google का कोडप्रो एनेलेटिक्स दिलचस्प लगता है। लेकिन "क्विस कस्टोडिएट ipsos कस्टोड?" परीक्षण कौन करता है? इसका उपयोग केवल मौजूदा परीक्षणों द्वारा इकाई परीक्षणों के बैकअप के लिए किया जा सकता है और संभवतः विफलताओं का पता नहीं लगाएगा, यह मान लेगा कि दोष सही हैं।
फाल्कन

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

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

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

मैं अगले हफ्ते इसका परीक्षण एक मध्यम आकार के J2EE एप्लिकेशन (120 klocs) के साथ करूँगा जो कुछ बहुत ही कठिन व्यावसायिक नियमों को शामिल करता है और आपको यहाँ अपने अनुभवों के बारे में बताता है।
फाल्कन

1

मैंने कुछ साल पहले .NET प्रोजेक्ट के लिए यूनिट टेस्टिंग को तेज करने के लिए एक जनरेटर लिखा था। बिना यूनिट परीक्षणों के साथ एक बड़ा कोडबेस था और इसका उद्देश्य मूल कवरेज को जल्दी से बढ़ाना था। यहां कुछ नोट दिए गए हैं जो मदद के हो सकते हैं:

  • मेरा मौका यह था कि इस परियोजना के शीर्ष पर मुख्य ढांचा विकसित किया गया था जो मानक संचालन और वर्ग के नामकरण प्रदान किया गया था। यदि आप अपना खुद का लिखने की सोच रहे हैं, तो इस तरह की एक मानक संरचना बहुत मदद करेगी।
  • data-driven testingयदि आपका कोडबेस अनुमति देता है, तो उपयोग करने से बहुत मदद मिलती है। परीक्षण ढांचे ने परीक्षण डेटा संग्रहीत करने के लिए प्रत्येक इकाई परीक्षण के लिए एक डेटाबेस तालिका बनाई, ताकि उस तालिका में प्रत्येक पंक्ति एक अलग परीक्षण हो और कोई अतिरिक्त कोड की आवश्यकता नहीं थी ( नियम का प्रतिनिधित्व )। इस बिंदु से, वास्तविक परीक्षणों को आसानी से स्वचालित रूप से बनाया जा सकता है या मैन्युअल रूप से दर्ज किया जा सकता है।
  • परिणामी इकाई परीक्षण सरल थे लेकिन उन्होंने smoke testकम से कम एस के रूप में सेवा की । उच्च जोखिम वाले क्षेत्रों के लिए, अतिरिक्त मैनुअल परीक्षण लिखे गए थे।

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

(साइड-नोट के रूप में, Pex है , लेकिन यह .NET के लिए है)

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.