2010-04-06 26 views
46

हमारे टूलकिट में 15000 JUnit परीक्षण हैं, और कुछ परीक्षण विफल होने के लिए कई परीक्षण विफल होने के लिए जाने जाते हैं। उदाहरण के लिए, यदि विधि X.foo() Y.bar() और YTest.testBar() से कार्यक्षमता का उपयोग करता है, तो XTest.testFoo() विफल हो जाएगा। जाहिर है, XTest.testFoo() X.foo() के लिए विशिष्ट समस्याओं के कारण भी विफल हो सकता है।मैं जुनीट परीक्षण निर्भरताओं को कैसे निर्दिष्ट कर सकता हूं?

हालांकि यह ठीक है और मैं अभी भी दोनों परीक्षणों को चलाने की इच्छा रखता हूं, तो यह अच्छा होगा अगर कोई XTest.testFoo() के साथ परीक्षण निर्भरता को एनटीएस्ट.testBar() पर इंगित कर सकता है। इस तरह, कोई तुरंत देख सकता है कि X.foo() द्वारा उपयोग की जाने वाली कार्यक्षमता भी असफल रही है, और क्या नहीं।

क्या जुनीट या अन्य जगहों पर ऐसी एनोटेशन उपलब्ध है? कुछ की तरह:

public XTest { 

    @Test 
    @DependsOn(method=org.example.tests.YTest#testBar) 
    public void testFoo() { 
    // Assert.something(); 
    } 

} 
+0

यह एक पुरानी धागा, फिर भी है: X.foo() Y.bar() का उपयोग करता है परीक्षण करना चाहिए नकली Y.bar(), अन्यथा (!) आपका परीक्षण यूनिट परीक्षण नहीं है (लेकिन एकीकरण परीक्षण)। यूनिट परीक्षणों का पूरा विचार कोई निर्भरता नहीं है। हालांकि, मैं यहां एक कारण के लिए हूं ;-) – letmejustfixthat

उत्तर

22

JExample और TestNG ऐसा ही कुछ किया है।

मुझे नहीं पता कि यह कितना उपयोगी है, लेकिन यदि आप इसे आजमाते हैं, तो कृपया हमें यह बताने के लिए वापस आएं कि यह उपयोगी था या नहीं।

+3

हाँ, यह एक उत्कृष्ट शुरुआत की तरह लगता है: http://chem-bla-ics.blogspot.com/2010/08/specifying-unit-test- निर्भरता- साथ। एचटीएमएल –

+1

कक्षा में जब यह स्थिति में उपयोगी है।methodA() ClassB.methodB() को आमंत्रित करता है और दोनों में बहुत समय लगता है। इस मामले में आप निर्दिष्ट कर सकते हैं कि testMethodA() testMethodB() पर निर्भर करता है, यह है कि testMethodB() विफल रहता है, testMethodA() निष्पादन के बिना ** विफल रहता है **। – Cherry

+0

@ चेरी: लिखने के लिए बहाने की तरह लगता है [फास्ट टेस्ट] (http://agileinaflash.blogspot.fi/2009/02/first.html)। डिज़ाइन में सुधार के लिए कुछ विकल्प: (1) विधि बी को तेज करें, (2) विधि बनाएं विधि ए पर निर्भर नहीं है, (3), कक्षा ए का परीक्षण करते समय कक्षाबी के लिए एक परीक्षण डबल का उपयोग करें। –

1

वास्तव में ऐसा कुछ नहीं है जिसे मैं जानता हूं। (संपादित करें: आप हर दिन कुछ नया सीखते हैं :)) मेरी राय में, यह किसी चीज का बुरा नहीं है (हालांकि मैं इसे उपयोगी साबित कर सकता हूं, खासकर जब जुनेट इसे स्वचालित परीक्षणों के अन्य रूपों के लिए उपयोग किया जा रहा है - उदाहरण के लिए, एकीकरण परीक्षण)। आपके परीक्षण, आईएमओ, "इकाई परीक्षण" शब्द की सख्त अर्थ में नहीं हैं (कम से कम X#foo() के लिए परीक्षण नहीं)। X#foo() के कार्यान्वयन पर X#foo() के लिए टेस्ट केवल पर निर्भर या विफल होना चाहिए। यह Y#foo() पर निर्भर नहीं होना चाहिए।

मैं आपकी स्थिति में क्या करूँगा वाई को मजाक करना, और MockY#foo() जैसे कुछ सरल, नियंत्रित व्यवहार के साथ कार्यान्वित करना, और X#foo() के परीक्षणों में इसका उपयोग करना है।

उसने कहा, 15,000 परीक्षणों के साथ, मैं देख सकता हूं कि यह कैसे प्रतिक्रिया करने वाला दर्द होगा। :)

+1

मुझे नहीं लगता कि इकाई परीक्षणों में निर्भरता क्यों नहीं हो सकती है ... हमारी टूलकिट डेटा ऑब्जेक्ट्स और एल्गोरिदम को परिभाषित करती है ... यदि कोई डेटा ऑब्जेक्ट विफल रहता है, तो आप कैसे करते हैं एल्गोरिदम को इसके लिए स्वचालित रूप से सही करने की उम्मीद है? शायद दोनों विधियों का नामकरण foo() भ्रामक था ... –

+0

केवल सख्त नकली परीक्षण एक दूसरे पर निर्भरता प्रदर्शित नहीं करेंगे (और फिर भी वे ...)। आम तौर पर, ऐसी निर्भरता हमेशा संभव होती है और ओओ डिजाइन में निर्भरताओं को प्रतिबिंबित करना पड़ता है। मेरा मानना ​​है कि सभी परीक्षणों में इस तरह की एनोटेशन को बनाए रखने से जटिल लाभ के बिना जटिलता में वृद्धि होगी, लेकिन कुछ मूल मामलों में ऐसी एनोटेशन होने से लाभ हो सकता है। – topchef

3

आप test dependencies in TestNG घोषित कर सकते हैं, वाक्यविन्यास लगभग आपके उदाहरण जैसा ही है। मुझे नहीं लगता कि जुनीट कुछ इसी तरह की पेशकश करता है।

+1

https://github.com/junit-team/junit.contrib/tree/master/assumes – jplandrain

1

behavior driven design लाइब्रेरी jBehave में एक कीवर्ड GivenScenarios है जो मुख्य परिदृश्य से पहले चल रहे परिदृश्यों की एक सूची आयात करता है। यह निर्भरताओं को परिभाषित करने और विफलता का एक बिंदु होने का अवसर प्रदान करता है। जेबीहेव की लॉगिंग आपको बताएगी कि परीक्षण निर्भरता या मुख्य निकाय अनुभाग में विफल रहता है या नहीं।

17

वहाँ JUnit कि इसके समाधान के लिए एक योगदान है: https://github.com/junit-team/junit.contrib/tree/master/assumes

+3

अच्छा, अच्छा! मुझे उम्मीद है कि यह जल्द ही विलय हो जाएगा :) –

+0

यह अभी तक मेवेन सेंट्रल में उपलब्ध नहीं है (http://search.maven.org/#search%7Cga%7C1%7Cjunit-contrib देखें)। आप इसका इस्तेमाल कैसे करते हैं? या अब आप कुछ और इस्तेमाल करते हैं? – koppor

3

org.junit.FixMethodOrder

@FixMethodOrder (MethodSorters.NAME_ASCENDING) यह आपके इकाई परीक्षण वर्ग के शीर्ष पर चला जाता है।

आप अपने तरीकों सार्वजनिक नाम कर सकते हैं शून्य step1_methodName आदि

संबंधित मुद्दे