यूनिट परीक्षण: अपेक्षित तर्क हमेशा समानता परीक्षणों में क्यों होता है?

Question

क्यों हर इकाई परीक्षण ढांचे (मैं :) के बारे में पता की आवश्यकता यह है कि कि समानता परीक्षण में उम्मीद मूल्य हमेशा पहला तर्क है:

Assert.AreEqual(42, Util.GetAnswerToLifeTheUniverseAndEverything()); 

assertEquals(42, Util.GetAnswerToLifeTheUniverseAndEverything()); 

आदि

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

Answer 1

मुझे लगता है कि यह सिर्फ एक सम्मेलन है और जैसा कि आप ने कहा कि यह ने भी अपनाया है "हर इकाई परीक्षण ढांचे (मैं के बारे में पता)"। यदि आप एक ढांचे का उपयोग कर रहे हैं तो यह विपरीत ढांचे का उपयोग करने वाले दूसरे ढांचे पर स्विच करने के लिए परेशान होगा। इसलिए (यदि आप उदाहरण के लिए एक नया यूनिट परीक्षण ढांचा लिख ​​रहे हैं) तो यह आपके लिए बेहतर होगा कि मौजूदा सम्मेलन का पालन करना भी बेहतर होगा। मेरा मानना ​​है कि इस तरह से कुछ डेवलपर्स उनके समानता परीक्षण लिखने के लिए पसंद करते हैं से आता है:

if (4 == myVar) 

गलती से किसी भी अवांछित काम से बचने के लिए, एक "=" के बजाय "==" का लेखन। इस मामले में संकलक इस त्रुटि को पकड़ लेगा और आप एक अजीब रनटाइम बग को ठीक करने की कोशिश कर रहे कई परेशानियों से बचेंगे।

Answer 2

कोई भी नहीं जानता और यह कभी भी भ्रमित होने का स्रोत नहीं है। हालांकि नहीं सभी व्यवस्थाएं इस पैटर्न (एक बड़ा भ्रम की स्थिति) का पालन करें:

1. FEST-Assert का उपयोग करता सामान्य आदेश:

   assertThat(Util.GetAnswerToLifeTheUniverseAndEverything()).isEqualTo(42); 
   

2. Hamcrest:

   assertThat(Util.GetAnswerToLifeTheUniverseAndEverything(), equalTo(42)) 
   

3. ScalaTest नहीं है वास्तव में एक भेद बनाओ:

   Util.GetAnswerToLifeTheUniverseAndEverything() should equal (42) 
   

Answer 3

मुझे नहीं पता, लेकिन मैं सामान्य रूप से समानता परीक्षणों के तर्कों के आदेश के बारे में कई एनिमेटेड चर्चाओं का हिस्सा रहा हूं।

लोग हैं, जो लगता है कि

if (42 == answer) { 
    doSomething(); 
} 

if (answer == 42) { 
    doSomething(); 
} 

सी-आधारित भाषाओं में बेहतर है की एक बहुत कुछ कर रहे हैं।

if (42 = answer) { 
    doSomething(); 
} 

आप एक संकलक त्रुटि दे देंगे, लेकिन

if (answer = 42) { 
    doSomething(); 
} 

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

Answer 4

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

जुनीट ने ऐसा क्यों किया? मुझे नहीं पता, केंट बेक से पूछो!

Answer 5

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

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

कहेंगे

बजाय

"इस परीक्षण में, मुझे यकीन है कि परिकलित मान 5 के बराबर है बनाना"

"इस परीक्षण में, मैं सुनिश्चित करता हूं कि 5 गणना मूल्य के बराबर है"।

अंतर बड़ा नहीं हो सकता है, लेकिन चलो इसे आगे बढ़ाएं। इस पर विचार करें:

Assert.That(Roses, Are(Red)); 

सही के बारे में लगता है। अब:

Assert.That(Red, Are(Roses)); 

एचएम ..? यदि आप किसी ने आपको बताया कि गुलाब लाल हैं तो शायद आपको आश्चर्य नहीं होगा। अन्य तरीकों के आसपास, लाल गुलाब, संदिग्ध प्रश्न उठाते हैं। Yoda, कोई भी?

योदा के एक महत्वपूर्ण बिंदु बनाने - think लिए आपको बलों को उलट दिया।

यह और भी हो जाता है अप्राकृतिक जब अपने दावे को और अधिक जटिल हैं:

Assert.That(Forest, Has.MoreThan(15, Trees)); 

आप कैसे रिवर्स होता है कि एक? वन द्वारा 15 से अधिक पेड़ लगाए जा रहे हैं?

यह दावा (संशोधन के लिए एक प्रेरणा कारक के रूप में प्रवाह) किसी भी तरह परिवर्तन में परिलक्षित होता है कि NUnit के माध्यम से चला गया है - मूल रूप से (Assert.AreEqual) यह उम्मीदवास्तविक से पहले (पुरानी शैली) का इस्तेमाल किया। Fluent एक्सटेंशन (या NUnit की शब्दावली का उपयोग करने के लिए, बाधा आधारित - Assert.That) उस आदेश को उलट दिया।

Answer 6

वैसे उन्हें एक सम्मेलन चुनना पड़ा। यदि आप इसे पीछे हटाना चाहते हैं तो हमक्रिस्ट मैचर्स को आजमाएं। वे पठनीयता बढ़ाने में मदद करने के लिए हैं। यहां एक मूल नमूना है:

import org.junit.Test; 
import static org.junit.Assert.assertThat; 
import static org.hamcrest.core.Is.is; 

public HamcrestTest{ 
    @Test 
    public void matcherShouldWork(){ 
     assertThat( Math.pow(2, 3), is(8) ); 
    } 
} 

Answer 7

निश्चित रूप से यह अनुमानित मूल्य को पहले रखने के लिए तार्किक अर्थ बनाता है, क्योंकि यह पहला ज्ञात मान है।

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

Answer 8

क्योंकि, दुर्भाग्य से, कई प्रोग्रामर Self-Reliance by Ralph Waldo Emerson पढ़ चुके हैं।