जुनीट बेस्ट प्रैक्टिस: प्रत्येक @ टेस्ट

Question

के लिए अलग फिक्स्चर मैं समझता हूं कि @Before और @BeforeClass हैं, जिनका उपयोग @Test के लिए फिक्स्चर को परिभाषित करने के लिए किया जाता है। लेकिन अगर मुझे प्रत्येक @Test के लिए अलग-अलग फिक्स्चर की आवश्यकता है तो मुझे क्या उपयोग करना चाहिए?

• क्या मुझे @Test में स्थिरता को परिभाषित करना चाहिए?
• क्या मुझे प्रत्येक @Test के लिए टेस्ट क्लास बनाना चाहिए?

मैं यहां सर्वोत्तम प्रथाओं के लिए पूछ रहा हूं, क्योंकि दोनों समाधान मेरी राय में साफ नहीं हैं। पहले समाधान के साथ, मैं प्रारंभिक कोड का परीक्षण करूंगा। और दूसरे समाधान के साथ मैं "प्रत्येक वर्ग के लिए एक टेस्ट क्लास" पैटर्न तोड़ दूंगा।

Answer 1

सुझाव:

1. वर्ग पैटर्न प्रति एक परीक्षण वर्ग को भूल जाओ, यह थोड़ा योग्यता है। प्रति उपयोग परिप्रेक्ष्य में एक टेस्ट क्लास पर स्विच करें। एक परिप्रेक्ष्य में आपके पास कई मामले हो सकते हैं: ऊपरी सीमा, निचली सीमा, आदि। उसी कक्षा में उन लोगों के लिए अलग @Tests बनाएं।
2. याद रखें कि जुनीट प्रत्येक @ टेस्ट के लिए टेस्ट क्लास का एक उदाहरण बनाएगा, इसलिए प्रत्येक टेस्ट को एक अलग स्थिरता मिलेगी (उसी तरीके से सेट की गई है)। यदि आपको असमानता की आवश्यकता है तो आपको एक अलग टेस्ट क्लास की आवश्यकता है, क्योंकि आप एक अलग परिप्रेक्ष्य में हैं (देखें 1.)
3. किसी विशेष परीक्षण के लिए स्थिरता में बदलाव करने में कुछ भी गलत नहीं है, लेकिन आपको परीक्षण को साफ रखने की कोशिश करनी चाहिए तो यह एक कहानी बताता है। परीक्षण विफल होने पर यह कहानी विशेष रूप से स्पष्ट होनी चाहिए, इसलिए प्रत्येक मामले के लिए अलग-अलग, अच्छी तरह से नाम @Test (देखें 1।)

Answer 2

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

Answer 3

यदि आप सकारात्मक हैं कि आपका स्थिरता एकल परीक्षण के लिए अद्वितीय है तो यह @Test विधि से संबंधित है। हालांकि यह सामान्य नहीं है। यह हो सकता है कि इसका कुछ हिस्सा अनूठा है या आपने इसे पैरामीट्रीज़/निकाला नहीं है, लेकिन आमतौर पर आप परीक्षण के बीच एक ही डेटा साझा करेंगे।

अंततः स्थिरता परीक्षण का हिस्सा है। @Before में स्थिरता रखने XUnit पैटर्न के रूप में अपनाया गया था, क्योंकि हमेशा परीक्षण:

1. परीक्षण डाटा तैयार/उपहास
2. SUT के साथ कार्रवाई करने
3. सत्यापित करें/जोर राज्य/व्यवहार
4. नष्ट परीक्षण डाटा/उपहास

और चरण 1 (@Before) और 4 (@After) संबंधित परीक्षणों में बहुत कम (कम से कम आंशिक रूप से) पुन: उपयोग किए जाते हैं। चूंकि xUnit परीक्षा आजादी के बारे में बहुत गंभीर है, यह गारंटी देने के लिए स्थिरता विधियों की पेशकश करता है कि वे हमेशा बनाए गए/नष्ट किए गए डेटा को चलाते हैं और परीक्षण करते हैं।