नामकरण इकाई और एकीकरण परीक्षण विधियों के लिए सर्वोत्तम अभ्यास?

Question

मैंने हाल ही में एक ऐसे एप्लिकेशन को विरासत में मिला है जो विभिन्न लोगों द्वारा अलग-अलग लोगों द्वारा लिखी गई है और मानकीकरण के तरीके पर मार्गदर्शन की तलाश में है।

Answer 1

NUnit मान लिया जाये:

[Test] 
public void ObjectUnderTest_StateChanged_Consequence() 
{ 
    Assert.That(tra_la_la); 
} 

[Test] 
public void ObjectUnderTest_Behaviour_Consequence() 
{ 
    Assert.That(tra_la_la); 
} 

उदाहरण के लिए:

[Test] 
public void WifeIsTired_TakeWifeToDinner_WifeIsGrateful() 
{ 
    Assert.That(tra_la_la); 
} 

[Test] 
public void WifeIsTired_MentionNewGirlfriend_WifeGetsHalf() 
{ 
    Assert.That(tra_la_la); 
} 

Answer 2

मैं दो अच्छे सुझावों में भाग गया। यहाँ लिंक: http://slott-softwarearchitect.blogspot.com/2009/10/unit-test-naming.html

http://weblogs.asp.net/rosherove/archive/2005/04/03/TestNamingStandards.aspx

http://openmrs.org/wiki/Unit_Testing_with_@should

Answer 3

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

Answer 4

मैं FunctionTestCondition निर्माण का उपयोग करता हूं। मैं दो तरीकों, Get और Set है, तो मैं शायद निम्नलिखित परीक्षण तरीकों बनाना होगा:

• GetTest सकारात्मक परीक्षण किया जा रहा है (सब कुछ ठीक है)।
• GetTestInvalidIndex विधि में पारित एक अवैध अनुक्रमणिका का परीक्षण करने के लिए।
• GetTestNotInitialized परीक्षण करने के लिए जब डेटा उपयोग में नहीं आया है तो परीक्षण करने के लिए।
• SetTest
• SetTestInvalidIndex
• SetTestTooLargeValue
• SetTestTooLongString

Answer 5

यह BDD (व्यवहार संचालित विकास) और विशेष रूप से this blog post को देखने के लिए शिक्षाप्रद है।

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

Answer 6

मैं बस लिखता हूं कि यह क्या है। ऐसा नहीं है कि आपको कहीं और नाम टाइप करना होगा, इसलिए testWibbleDoesNotThrowAnExceptionIfPassedAFrobulator कोई समस्या नहीं है। कुछ भी जो परीक्षण है, स्पष्ट रूप से 'परीक्षण' से शुरू होता है।

Answer 7

सेटअप द्वारा अपने परीक्षणों को समूहित करें, इस सेटअप के आसपास एक टेस्ट क्लास बनाएं और नाम प्रत्यय परीक्षण या एकीकरण टेस्ट के साथ है। JUnit या TestNG जैसे परीक्षण ढांचे का उपयोग करके आप अपनी परीक्षा विधियों को नाम दे सकते हैं। मैं जिस विधि का परीक्षण करता हूं, ऊंट मामले में एक वाक्य, परीक्षण उपसर्ग नहीं, मैं विधि का नाम दूंगा। फ्रेमवर्क एक विधि के रूप में चिह्नित करने के लिए @Test एनोटेशन का उपयोग करते हैं।

Answer 8

ऐसे, अलग अलग लोगों के रूप में कोई मानक नहीं है/स्थानों विभिन्न योजनाओं होगा।महत्वपूर्ण बात यह है कि आप मानक के लिए छड़ी चिपकते हैं।

व्यक्तिगत तौर पर मैं निम्नलिखित के एक प्रशंसक हूँ - सी # में उदाहरण कोड है, लेकिन बहुत जावा के करीब है, वही नियम लागू:

[Test] 
public void person_should_say_hello() 
{ 
    // Arrange 
    var person = new Person(); 
    // Act 
    string result = person.SayHello(); 
    // Assert 
    Assert(..., "The person did not say hello correctly!"); 
} 

स्पष्ट

परीक्षण नाम नाम देना चाहिए परीक्षण के तहत कक्षा के। इस उदाहरण में, परीक्षण किया जा रहा वर्ग Person है। परीक्षण नाम में उस विधि का नाम होना चाहिए जिसका परीक्षण किया जा रहा है। इस तरह, यदि परीक्षण विफल होना था, तो आप कम से कम यह जान लेंगे कि इसे हल करने के लिए कहां देखना है। मैं AAA - Arrange, Act, Assert नियम का पालन करने की भी सिफारिश करता हूं, यह सुनिश्चित करेगा कि आपके परीक्षण पढ़ने और अनुसरण करने में आसान हैं।

अनुकूल संदेशों

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

रेखांकित

अंतिम (हालांकि वैकल्पिक) रुख मैं पालन परीक्षण नाम के लिए अंडरस्कोर उपयोग कर रहा है। जबकि मैं उत्पादन कोड में अंडरस्कोर का कोई प्रशंसक नहीं हूं, परीक्षण नामों में उनका उपयोग उपयोगी है क्योंकि परीक्षण नाम अक्सर अधिक लंबे होते हैं। अंडरस्कोर का उपयोग करने वाले परीक्षण नाम पर तेज़ी से चमकना बहुत अधिक पठनीय साबित होता है, हालांकि यह व्यक्तिपरक परीक्षण इकाइयों के संबंध में व्यक्तिपरक और बहस का स्रोत है।

एकता टेस्ट

एकीकरण परीक्षण करने के लिए एक ही मानकों को लागू, फर्क सिर्फ इतना है इस तरह के परीक्षणों इकाई परीक्षण से अलग किया जाना चाहिए के स्थान जा रहा है। उपर्युक्त उदाहरण कोड में, टेस्ट क्लास को PersonTests कहा जाएगा और PersonTests.cs नामक फ़ाइल में स्थित होगा। एकीकरण परीक्षणों का नाम इसी तरह से रखा जाएगा - PersonIntegrationTests, PersonIntegrationTests.cs में स्थित है। इन परीक्षणों के लिए एक ही प्रोजेक्ट का उपयोग किया जा सकता है, लेकिन यह सुनिश्चित करें कि वे अलग-अलग निर्देशिकाओं में स्थित हैं।