एक परीक्षण में कई स्थितियों का दावा करें, या एकाधिक परीक्षणों में विभाजित करें?

Question

यदि आप नीचे दिए गए की तरह एक गिनती फ़ंक्शन का परीक्षण कर रहे थे, तो क्या इसे प्रत्येक फ़ंक्शन के लिए एक फ़ंक्शन फ़ंक्शन बनाम एक फ़ंक्शन में फ़ंक्शन के लिए एकाधिक चीज़ों का परीक्षण करने के लिए 'दाएं' या 'गलत' माना जाता है?

function testGetKeywordCount() { 
    $tester = $this -> getDatabaseTester($this -> CompleteDataFile); 
    $tester -> onSetUp(); 

    $KeywordID = 0; 
    $this -> setExpectedException('InvalidArgumentException'); 
    $this -> keyword -> getKeywordCount($KeywordID,'Active'); 

    $KeywordID = 1; 
    $this -> setExpectedException('InvalidArgumentException'); 
    $this -> keyword -> getKeywordCount($KeywordID,'InvalidStatus'); 

    $this -> assertEquals(1, $this -> keyword -> getKeywordCount($KeywordID,'Active')); 

    $tester -> onTearDown(); 
} 

Answer 1

आपके पास कई परीक्षण कार्य होना चाहिए, जहां प्रत्येक अपनी स्थिति का परीक्षण करता है। इस तरह डीबगिंग के बिना विफलता को खोजना आसान है।

Answer 2

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

मैं इकाई परीक्षण पर जितना संभव हो उतना कम समय बिताना पसंद करता हूं, और उस समय भी जितना संभव हो उतना कवरेज प्राप्त करता हूं।

अंत में, यह यूनिट परीक्षण को कार्यान्वित करने के तरीके से कम है, लेकिन उन परीक्षणों की शुद्धता अधिक है।

Answer 3

परीक्षण ढांचे हमेशा टेस्ट नियम के एक दावे का पालन करने के आपके प्रयास के लायक नहीं बनाते हैं।

रूबी के लिए RSpec है जो आपको nested example groups सेट करने की अनुमति देता है। उदाहरण के लिए:

• एक उपयोगकर्ता
  • एक पासवर्ड
    • बिना अवैध है
    • अपवाद
  • फेंकता एक पासवर्ड
    • कि कर दिया गया है साथ इस्तेमाल किया पहले
      • अमान्य है
      • अपवाद फेंकता
      • यात्राएं सुरक्षा चेतावनी
    • है इस्तेमाल किया गया है कि नहीं से पहले
      • मान्य है
      • खाते में पेज
      पुनर्निर्देश

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

Answer 4

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

लेकिन इस मामले में कई दावे होने के लिए ठीक है।

बस यह सुनिश्चित करें कि 2 दावे दूसरे के पीछे नहीं हैं।

बुरा उदाहरण

public void ValidateRulesEntry_Valid_ValidConditionsFromFile() 
{ 
    string condition = "Target.HasValue"; 
    string returnMessage; 

    bool successFul = CodeParserTryParseCondition(condition, out returnMessage); 


    Assert.IsTrue(successFul); 
    Assert.IsFalse(string.IsNullOrEmpty(returnMessage)); 
    Assert.IsTrue(returnMessage == "OK"); 

} 

2 पिछले दावे IsTrue (सफल) 1 दावे की निर्भर हैं।

सोचो के बारे में: है कि परीक्षण में विफल रहता है -> बताओ मुझे क्यों दो अलग-अलग परीक्षण में दावे विभाजित करने के लिए

Answer 5

एक तर्क (डिबग आउटपुट में देख के बिना) है कि, अगर दावे में से एक में विफल रहता है, तो आप ' एक विफलता मिल जाएगी; यदि दोनों दावे विफल हो जाते हैं, तो आपको दो विफलताओं मिल जाएगी।

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

Answer 6

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

तो, कौन सही है?

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

तो, बड़े खिलाड़ी अपनी परियोजनाओं का परीक्षण कैसे करते हैं? और अधिक महत्वपूर्ण बात यह है कि यूनिट परीक्षण ढांचे को यूनिट का परीक्षण कैसे किया जाता है?

चलो कुछ उदाहरण देखें:

हाइबरनेट

https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/engine/spi/EntityEntryTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/engine/spi/NonSortedExecutableListTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/engine/spi/SortedExecutableListTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-envers/src/test/java/org/hibernate/envers/test/JpaStaticMetamodelTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-hikaricp/src/test/java/org/hibernate/test/hikaricp/HikariCPConnectionProviderTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-proxool/src/test/java/org/hibernate/test/proxool/ProxoolConnectionProviderTest.java

स्प्रिंग

https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/test/java/org/springframework/util/AntPathMatcherTests.java https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/test/java/org/springframework/util/ClassUtilsTests.java https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/test/java/org/springframework/util/ObjectUtilsTests.java https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/test/java/org/springframework/util/AutoPopulatingListTests.java

JUnit 4

https://github.com/junit-team/junit4/blob/master/src/test/java/junit/tests/extensions/ActiveTestTest.java https://github.com/junit-team/junit4/blob/master/src/test/java/junit/tests/extensions/RepeatedTestTest.java https://github.com/junit-team/junit4/blob/master/src/test/java/junit/tests/runner/ResultTest.java https://github.com/junit-team/junit4/blob/master/src/test/java/org/junit/rules/TimeoutRuleTest.java

JUnit 5

https://github.com/junit-team/junit5/blob/master/platform-tests/src/test/java/org/junit/platform/launcher/core/DefaultLauncherTests.java https://github.com/junit-team/junit5/blob/master/platform-tests/src/test/java/org/junit/platform/launcher/core/LauncherDiscoveryRequestBuilderTests.java https://github.com/junit-team/junit5/blob/master/platform-tests/src/test/java/org/junit/platform/launcher/listener/SummaryGenerationTests.java https://github.com/junit-team/junit5/blob/master/junit-jupiter-engine/src/test/java/org/junit/jupiter/engine/StandardTestClassTests.java https://github.com/junit-team/junit5/blob/master/junit-jupiter-engine/src/test/java/org/junit/jupiter/engine/DiscoveryFilterApplierTests.java

गूगल सत्य

https://github.com/google/truth/blob/master/core/src/test/java/com/google/common/truth/DoubleSubjectTest.java https://github.com/google/truth/blob/master/core/src/test/java/com/google/common/truth/BigDecimalSubjectTest.java https://github.com/google/truth/blob/master/core/src/test/java/com/google/common/truth/DoubleSubjectTest.java

हम उपरोक्त उदाहरण में देख सकते हैं, पेशेवर डेवलपर्स एकल ज़ोर आज्ञा के बारे में ज्यादा देखभाल करने के लिए प्रतीत नहीं होता। वास्तव में, वे इस नियम को ज्यादातर समय तोड़ते हैं और ऐसा लगता है कि वे इसके साथ बिल्कुल ठीक हैं। शायद वे इसे अनदेखा करते हैं क्योंकि सख्त नियम नहीं है बल्कि सिर्फ एक सिफारिश है। यह उल्लेखनीय है कि यूनिट परीक्षण फ्रेमवर्क भी परीक्षण के दौरान प्रति परीक्षण एक से अधिक assert के साथ खुद का परीक्षण करते हैं।

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