क्या आपके एनयूनीट यूनिट परीक्षण

Question

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

क्या आप एनयूनीट में परीक्षणों का आदेश भी निर्धारित कर सकते हैं या क्या वे हमेशा वर्णानुक्रम से किए जाते हैं?

नोट: मैं विशेष रूप से एक परीक्षण फ़ाइल के भीतर परीक्षणों के आदेश के बारे में पूछ रहा हूं। परीक्षण फ़ाइलों में या किसी भी तरह से अधिक वैश्विक स्तर पर नहीं।

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

Answer 1

आपके परीक्षणों के क्रम पर निर्भर करते हुए संकेत मिलता है कि आप परीक्षणों में राज्य बना रहे हैं। यह smelly

है टेस्टिंग का एक क्लीनर तरीका है जहाँ आप केवल कार्यक्षमता का एक टुकड़ा आप के व्यवहार की जांच करना चाहते पर निर्भर हैं। आम तौर पर आप mock अन्य ऑब्जेक्ट्स जिन्हें आपको कार्य करने के लिए परीक्षण के तहत अपनी विधि प्राप्त करने की आवश्यकता होती है।

यूनिट परीक्षणों के बारे में सोचने का एक अच्छा तरीका Arrange, Act, Assert पैटर्न है।

नीचे कार्ल सेगुइन के उत्कृष्ट मुक्त eBook से एक स्निपेट है। मैंने व्यवस्था, अधिनियम और जोर दिया है।

[TestFixture] public class CarTest 
{ 
    [Test] public void SaveCarCallsUpdateWhenAlreadyExistingCar() 
    { 
     //Arrange 
     MockRepository mocks = new MockRepository(); 
     IDataAccess dataAccess = mocks.CreateMock<IDataAccess>(); 
     ObjectFactory.InjectStub(typeof(IDataAccess), dataAccess); 
     //Act 
     Car car = new Car(); 
     Expect.Call(dataAccess.Save(car)).Return(389); 
     mocks.ReplayAll(); 
     car.Save(); 
     mocks.VerifyAll(); 
     // Assert 
     Assert.AreEqual(389, car.Id); 
     ObjectFactory.ResetDefaults(); 
    } 
} 

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

मैं दृढ़ता से सलाह देता हूं कि आपके सभी यूनिट परीक्षण स्वतंत्र हो जाएं।

आपका व्यावसायिक तर्क/डेटाबेस संरचना इत्यादि समय के साथ बदल सकता है, ताकि आपको अंततः मौजूदा यूनिट परीक्षणों को प्रतिस्थापित या फिर से लिखना (या यहां तक ​​कि त्यागना) - और यदि आपके पास कई अन्य परीक्षण हैं जो आपके आधार पर हैं बदले में, इससे अनावश्यक परेशानी हो सकती है क्योंकि आपको अन्य सभी परीक्षणों के माध्यम से भी जाना होगा और जांचें कि क्या ये अभी भी अपेक्षित काम कर रहे हैं या नहीं।

इसके अतिरिक्त, एक असफल इकाई परीक्षण कई अन्य लोगों को खींचने में सक्षम नहीं होना चाहिए (जो पूरी तरह से अपने आप पर काम कर सकते हैं)।

Answer 8

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

यही कारण है कि आप जब चाहें परीक्षण स्वतंत्र चाहते हैं - इंट्रा-फाइल और इंटर-फाइल दोनों।

विभिन्न फ़ाइलों में परीक्षण (सेट) के बीच क्रम पर निर्भर होना बहुत मूर्ख नहीं होगा।