आप कैसे उबाऊ परीक्षण नहीं करते हैं?

Question

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

मुझे यह करने से लगभग 2-3 कीड़े और कभी-कभी प्रमुख लोग मिलते हैं। और अगर मैं ऐसा नहीं कर रहा हूं तो क्लाइंट एक और बग रिपोर्ट करता है।

तो मुझे बताएं कि आप अपने कोड का परीक्षण करने में किस तकनीक का उपयोग करते हैं, इस तरह से यह आपको नहीं बोलेगा?

संपादित करें:

मुझे लगता है कि मैं विशेष रूप से वेब आधारित क्षुधा पर काम कर रहा हूँ और मेरी भाषा पीएचपी & CakePHP रूपरेखा है उल्लेख करना भूल गया।

Answer 1

में तेजी से परीक्षण कर सकते हैं।(अधिक) तत्काल प्रतिक्रिया कम पुनरावृत्तियों को प्राप्त करने में मदद करता है। यह आपको अगले टेस्ट रन को शुरू करने के लिए लगभग आदी बना सकता है।

Answer 2

नए कोड के लिए, कोड को क्या करना चाहिए, यह बताएं कि एक कोड लिखें जो यह करता है कि कोड करता है, इसे कैसे करें, फिर कोड लिखें।

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

यह उबाऊ नहीं है, क्योंकि दोनों मामलों में परीक्षणों में विफलता की उच्च संभावना होती है।

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

Answer 3

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

Answer 4

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

यदि आप प्रोग्रामिंग को इस तरह से आजमाते हैं..मेरे दृष्टिकोण के मुताबिक, अधिक से अधिक मजेदार हो जाता है।

Answer 5

मेरी टीम को दी गई सलाह में से एक यह है कि एक नई विशेषताओं के बारे में 90% तर्क आवेदन के संदर्भ से बाहर होना चाहिए।

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

यदि आप .NET का उपयोग कर रहे हैं, तो आप NUnit की जांच कर सकते हैं।

आप Pex पर भी देख सकते हैं। यह एक अद्भुत परीक्षण ढांचा प्रतीत होता है।

हालांकि, आपका प्रश्न थोड़ा सामान्य है क्योंकि बहुत सारे परीक्षण प्रकार हैं।

मज़ेदार परीक्षण करें :)।

Answer 6

आप शायद उबाऊ होने के बजाय थकाऊ मतलब है। यदि ऐसा है, तो this article

Answer 7

"कोई परीक्षण नहीं, कोई उबाऊ नहीं।"

Answer 8

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

आपको यहां की आवश्यकता है परीक्षण के प्रति आपके दृष्टिकोण में बदलाव ... और अधिक विशेष रूप से ... आप कैसे परीक्षण कर रहे हैं में बदलाव। आप परीक्षण की तुलना में एक बहुत अधिक प्रोग्रामिंग प्यार ... अच्छी तरह से अपने परीक्षण कार्यक्रम ... तो यह बात प्रोग्रामिंग के साथ शुरू के रूप में सिर्फ मनोरंजन के रूप में है ... और जब आप समाप्त कर आप

1. एक कार्यक्रम है कि काम करता है

2. टेस्ट स्वीट कि रहता है और परीक्षण यह हर बनाता

तो छोड़ कि कदम डिबगर द्वारा चादर और कदम उत्कृष्टता और :-)

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

मुबारक कोडिंग और विस्तार से .. खुश परीक्षण :-)

---

कुछ संदर्भ जो आपके लिए उपयोगी हो सकता है, मैं एक PHP विशेषज्ञ, यह से दूर नहीं कर रहा हूँ, लेकिन यह उद्देश्य फिट करने के लिए लग रहा था।

• http://www.simpletest.org/
• http://www.phpunit.de/
• http://laughingmeme.org/2003/08/05/a-few-tips-for-writing-useful-libraries-in-php/

Answer 9

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

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

1. बस एक परीक्षा लिखने के लिए पर्याप्त लिखने के लिए पर्याप्त लिखें। उदा। आप कक्षा में एक विधि जोड़ रहे हैं, इसलिए आप इसे संकलित करने के लिए आवश्यक विधि सिग और किसी भी वापसी कथन को लिखते हैं।
2. फिर आप अपना पहला परीक्षण लिखते हैं और यह देखने के लिए ढांचे को चलाते हैं कि यह विफल रहता है।
3. फिर परीक्षा उत्तीर्ण करने के लिए आप अपनी विधि को कोड/रीफैक्टर जोड़ते हैं।
4. फिर आप अगला परीक्षण जोड़ते हैं और देखते हैं कि यह विफल रहता है।
5. 3 और 4 दोहराएँ जब तक कि आप किसी और परीक्षण के बारे में सोच नहीं सकते।
6. आप समाप्त कर चुके हैं।

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

एक और अच्छी बात यह है कि जब आप बाद में एक बग खोजते हैं, तो आप ज्ञान में अपने कोड को फिर से सक्रिय करना शुरू कर सकते हैं कि सभी मौजूदा परीक्षण साबित होंगे कि आपका कोड अभी भी सभी ज्ञात मामलों के लिए काम करता है, जबकि नए परीक्षण आप ' जब आप इसे ठीक कर लेंगे तो बग को फिर से बनाने के लिए लिखा जाएगा।

आप मौजूदा कोड में यूनिट परीक्षण जोड़ सकते हैं - बस उन बिट्स के लिए जोड़ें जिन्हें आप बदल रहे हैं। जैसे ही आप इसे वापस आते रहते हैं, परीक्षण अधिक से अधिक कवरेज प्राप्त करेंगे।

xUnit विभिन्न भाषाओं का समर्थन करने वाले ढांचे के समूह के लिए सामान्य नाम है: जावा के लिए जुनीट, .NET के लिए एनआईएनआईटी आदि। आपके द्वारा उपयोग की जाने वाली किसी भी भाषा के लिए शायद पहले से ही एक है। आप write your own framework भी कर सकते हैं। इस पुस्तक को पढ़ें - यह उत्कृष्ट है।

Answer 10

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

Answer 11

लिखें स्वत: इकाई परीक्षण, PhpUnit या Simpletest साथ के बाद से आप PHP का उपयोग कर रहे हैं, या अपनी पसंद के भाषा के लिए किसी अन्य unit-testing framework उपलब्ध। Test-Driven Development (टीडीडी) के बाद, आप अपने कोड के साथ एक परीक्षण सूट का निर्माण करेंगे। आपके पास कोई इंप्रेशन नहीं होगा जिसका आप परीक्षण कर रहे हैं। वास्तव में।

"* थोड़ा परीक्षण करें, थोड़ा कोड * *।

Answer 12

कुछ यूनिट परीक्षण/स्वचालित परीक्षण लिखें, जो स्वचालित रूप से चलेंगे। एक नया निर्माण करने के बाद।

encapsulation का उपयोग करें और केवल इंटरफेस के खिलाफ परीक्षण करने का प्रयास करें।

अपने मॉड्यूल/कक्षाओं का परीक्षण करने में आपकी सहायता के लिए कुछ छोटे टूल लिखें।

Answer 13

उपयोग करने में आसान बनाना, परीक्षण सूट पर्ल कार्यक्रमों के लिए करना आसान है। Test Anything Protocol का उपयोग कर पर्ल में परीक्षण करने का एक मानक तरीका है।

असल में आप .t एक्सटेंशन के साथ फ़ाइलों का एक समूह लिखते हैं, t/ आपकी प्रोजेक्ट की निर्देशिका में, और फिर prove चलाएं।

t/ में फ़ाइलों को मूल रूप से इस तरह दिखेगा:

#!/usr/bin/perl 
use strict; 
use warnings; 

use Test::More tests => 8; 

use Date::ICal; 

$ical = Date::ICal->new(year => 1964, month => 10, day => 16, 
         hour => 16, min => 12, sec => 47, 
         tz => '0530'); 

ok(defined $ical,   'new() returned something'); 
ok($ical->isa('Date::ICal'), " and it's the right class"); 
is($ical->sec,  47,  ' sec()' ); 
is($ical->min,  12,  ' min()' );  
is($ical->hour, 16,  ' hour()' ); 
is($ical->day,  17,  ' day()' ); 
is($ical->month, 10,  ' month()'); 
is($ical->year, 1964,  ' year()' ); 

अधिक जानकारी के लिए आप tutorial पढ़ सकते हैं।

ऐसी कई भाषाएं हैं जिनमें TAP के साथ काम करने के लिए डिज़ाइन किए गए मॉड्यूल हैं, अधिक जानकारी के लिए here देखें।

दुर्भाग्यवश, टीएपी का हाल ही में पर्ल की तुलना में अन्य भाषाओं के लिए उपयोग किया गया है, इसलिए उनके लिए उतना ही समर्थन नहीं है, जैसा कि पर्ल के लिए मौजूद है।

Answer 14

पहले परीक्षण के पहले दृष्टिकोण \ जोड़ी प्रोग्रामिंग परीक्षण का उपयोग करें।

यदि आप अपना कोड लिखने के बाद उन्हें लिखते हैं, तो आपका लक्ष्य आपके काम में गलतियों को ढूंढना है = दुखद लक्ष्य।

इसके विपरीत, यदि आप कोड से पहले अपने परीक्षण लिखते हैं, तो आपका लक्ष्य दोषपूर्ण सॉफ़्टवेयर = खुश लक्ष्य लिखना है।

Answer 15

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

काफी विपरीत, गैर-तुच्छ एल्गोरिदम & तर्क के लिए परीक्षण लिखना, कोने के मामलों की खोज करना जिन्हें आपने नहीं सोचा था वास्तव में मजेदार और बहुत ही पुरस्कृत अनुभव है।