सर्वोत्तम परीक्षण के नामकरण का यूनिट परीक्षण [बंद]

Question

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

यूनिट टेस्ट के लिए कुछ लोकप्रिय नामकरण सम्मेलनों में एसओ पर यह पहले चर्चा की गई थी ।

मुझे नहीं पता कि यह बहुत अच्छा दृष्टिकोण है, लेकिन वर्तमान में मेरी परीक्षण परियोजनाओं में, मेरे पास प्रत्येक उत्पादन वर्ग और एक परीक्षण वर्ग, जैसे Productऔर के बीच एक-से-एक मैपिंग है ProductTest।

मेरे परीक्षण वर्गों में मेरे पास तब विधियों के नाम हैं जिनके साथ मैं परीक्षण कर रहा हूं, एक अंडरस्कोर, और फिर स्थिति और मैं क्या होने की उम्मीद करता हूं, जैसे Save_ShouldThrowExceptionWithNullName()।

Comments

यहाँ देखें: stackoverflow.com/questions/96297/…

— भूले हुए अर्धविराम सेप

यह आपके प्रश्न का उत्तर नहीं देता है, लेकिन पढ़ने लायक है: haacked.com/archive/2012/01/02/structuring-unit-tests.aspx

— Robs

Google शैली मार्गदर्शिका कहती है: test<MethodUnderTest>_<state>जैसे कि testPop_emptyStack google-styleguide.googlecode.com/svn/trunk/javaguide.html 5.2.3 विधि के नाम। जब संदेह हो, तो Google का अनुसरण करें।

— सिरो सेंटिल्ली 郝海东 iro iro 法轮功 ''

@CiroSantilli 六四 事件 ill 卓 轩 the और अगला वाक्य कहता है: "परीक्षण विधियों को नाम देने का कोई एक सही तरीका नहीं है"। जाओ पता लगाओ।

— user2418306

मैं अभी भी सालों बाद भी फिल हैक की सिफारिश पसंद करता हूं ।

— pimbrouwers

Answer 1

मुझे रॉय ओशेरोव के नामकरण की रणनीति पसंद है , यह निम्नलिखित है:

[UnitOfWork_StateUnderTest_ExpectedBehavior]

यह विधि नाम पर और संरचित तरीके से आवश्यक हर जानकारी है।

काम की इकाई एकल विधि, एक वर्ग या कई वर्गों जितनी बड़ी हो सकती है। यह उन सभी चीजों का प्रतिनिधित्व करना चाहिए जिन्हें इस परीक्षण मामले में परीक्षण किया जाना है और नियंत्रण में हैं।

असेंबली के लिए मैं ठेठ .Testsअंत का उपयोग करता हूं , जो मुझे लगता है कि काफी व्यापक है और कक्षाओं के लिए समान है (समाप्त होने के साथ Tests):

[NameOfTheClassUnderTestTests]

पहले मैंने टेस्ट के बजाय फिक्सेचर को प्रत्यय के रूप में इस्तेमाल किया था, लेकिन मुझे लगता है कि उत्तरार्द्ध अधिक सामान्य है, फिर मैंने नामकरण की रणनीति बदल दी।

Comments

मेरे लिए यह विधि परीक्षण विधि में नाम रखने का कोई मतलब नहीं है। क्या होगा यदि आप विधि का नाम बदलें? कोई भी रिफैक्टरिंग उपकरण आपके लिए परीक्षणों का नाम नहीं बदलेगा। आखिरकार आप परीक्षण के तरीकों को हाथ से खत्म कर देते हैं या अधिक गलत तरीके से नाम वाले परीक्षण होने की संभावना रखते हैं। यह टिप्पणियों के साथ की तरह है। बहुत बुरा है तो कोड पर टिप्पणी नहीं।

— पायोत्र पेरक

@ पीरी, मुझे लगता है कि यह एक व्यापार है। एक ओर आपके परीक्षण के नाम पुराने हो सकते हैं, दूसरी ओर आप यह नहीं बता सकते कि आपका परीक्षण किस पद्धति से हो रहा है। मुझे लगता है कि उत्तरार्द्ध बहुत अधिक बार आता है।

— जोएल मैकबेथ

पेरी की टिप्पणी में जोड़ने के लिए - सभी तरीके कुछ कार्रवाई के लिए जिम्मेदार हैं, उदाहरण के लिए UpdateManager.Update()। इसे ध्यान में रखते हुए मैं अपने परीक्षणों को बुलाने के लिए WhenUpdating_State_Behaviourया WhenUpdating_Behaviour_State। इस तरह से मैं एक टेस्ट नाम में एक विधि नाम रखने से परहेज करते हुए एक वर्ग की एक विशेष कार्रवाई का परीक्षण करता हूं। लेकिन सबसे महत्वपूर्ण बात यह है कि मेरे पास एक सुराग होना चाहिए कि जब मैं एक असफल परीक्षा का नाम देखता हूं तो क्या व्यावसायिक तर्क विफल हो रहा है

— रामानुस

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

— जेफ मार्टिन

अच्छी विधि के नाम अक्सर क्रिया विधि के समान होते हैं। यदि आपको अपनी विधि के बाद अपने परीक्षण के नामकरण के बीच निर्णय करना है या क्रिया विधि करती है जो एक संकेत हो सकता है तो आपको अपनी पद्धति का नाम बदलना चाहिए । (हालांकि हर मामले में नहीं)

— कादज़िया

Answer 2

मैं परीक्षण के तहत इकाई (यानी वर्ग) के बाद परीक्षण स्थिरता का नामकरण करते समय परीक्षणों के लिए "चाहिए" नामकरण मानक का पालन करना पसंद करता हूं ।

समझाने के लिए (C # और NUnit का उपयोग करके):

[TestFixture]
public class BankAccountTests
{
  [Test]
  public void Should_Increase_Balance_When_Deposit_Is_Made()
  {
     var bankAccount = new BankAccount();
     bankAccount.Deposit(100);
     Assert.That(bankAccount.Balance, Is.EqualTo(100));
  }
}

क्यों "चाहिए" ?

मुझे लगता है कि यह परीक्षण लेखकों को एक वाक्य के साथ "किसी राज्य में होना चाहिए] [बाद में / पहले / जब] [क्रिया होती है]" की तर्ज पर नाम रखने के लिए मजबूर करता है।

हां, हर जगह "चाहिए" लिखने से थोड़ा दोहराव मिलता है, लेकिन जैसा कि मैंने कहा कि यह लेखकों को सही तरीके से सोचने के लिए मजबूर करता है (इसलिए नौसिखियों के लिए अच्छा हो सकता है)। इसके अलावा यह आम तौर पर एक पठनीय अंग्रेजी परीक्षा के नाम पर होता है।

अपडेट :

मैंने देखा है कि जिमी बोगार्ड भी 'चाहिए' का प्रशंसक है और यहां तक ​​कि एक यूनिट टेस्ट लाइब्रेरी भी है जिसे चाहिए कहा जाता है ।

अपडेट (4 साल बाद ...)

रुचि रखने वालों के लिए, नामकरण परीक्षणों के लिए मेरा दृष्टिकोण वर्षों में विकसित हुआ है। के साथ मुद्दों में से एक चाहिए पैटर्न मैं अपनी आसान नहीं जैसा कि ऊपर वर्णन एक नज़र में विधि में पता करने के लिए परीक्षण किया जा रहा है। ओओपी के लिए मुझे लगता है कि परीक्षण के नाम को परीक्षण के तहत विधि के साथ शुरू करना अधिक समझ में आता है। एक अच्छी तरह से डिजाइन किए गए वर्ग के लिए इसका परिणाम पठनीय परीक्षण विधि के नाम होना चाहिए। मैं अब इसी तरह के एक प्रारूप का उपयोग करता हूं <method>_Should<expected>_When<condition>। स्पष्ट रूप से संदर्भ के आधार पर आप कुछ अधिक उपयुक्त के लिए चाहिए / जब क्रियाओं का विकल्प देना चाहते हैं। उदाहरण: Deposit_ShouldIncreaseBalance_WhenGivenPositiveValue()

Comments

शायद इससे भी बेहतर और कम निरर्थक, बस एक वाक्य लिखें जो बताता है कि यह क्या करता है, परीक्षण काम करता है increasesBalanceWhenDepositIsMade():।

— hotshot309

हाल ही में एक लेख देखा जिसमें इसी तरह के नामकरण सम्मेलन का उल्लेख किया गया (काश मैं इसे बुकमार्क करता)। परीक्षण स्थिरता द्वारा क्रमबद्ध किए जाने पर परीक्षणों की सूचियों को बहुत पठनीय बनाने के लिए डिज़ाइन किया गया। आपको "BankAccount" जैसा कुछ दिखाई देता है, फिर इसके नीचे (अलग-अलग लाइनों पर) "Should_Increase_Balance_When_Deposit_Is_Made" "Should_Decrease_Balance_When_With_al_Is_Made", इत्यादि बहुत से एक विनिर्देशन को पढ़ता है, जो कि TDD के बारे में सभी के अनुसार है।

— साइमन तिवेई

लेख मिला। यह जस्टिन एथरेज के कोडहिन्क्ड ब्लॉग बिगिनिंग मॉकिंग विथ Moq 3 - भाग 1 में है ।

— सिमोन तिवसी

मैं भी जब और जब दूसरे रास्ते का उपयोग करना चाहिए। उदाहरण के लिए जबCCCererDoesNotExist_ShouldThrowException ()। मेरे लिए यह तब की तुलना में बहुत अधिक मायने रखता है जब (यानी एक निश्चित परिदृश्य में एक निश्चित अपेक्षित परिणाम होना चाहिए)। यह एएए (व्यवस्था, अधिनियम, मुखर) के साथ भी फिट बैठता है ...

— मुखर

@ श्नाइडर: "चाहिए" = "अनुशंसित" पर विचार करना तब वैकल्पिक है, मुझे आश्चर्य है कि क्या यह "आवश्यक" = "आवश्यक" / उपयोग करने के लिए बेहतर नहीं होगा। उदाहरण के लिए, RFC दोनों के बीच अंतर करता है। तो परीक्षण पास होने की सिफारिश की या आवश्यकता है?

— अश्वेत छिपकली

Answer 3

मुझे यह नामकरण शैली पसंद है:

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

और इसी तरह। यह गैर-परीक्षक को वास्तव में स्पष्ट करता है कि समस्या क्या है।

Comments

लेकिन @ hotshot309, वह

— ऐस

@ हाँ, मैं आपसे पूरी तरह सहमत हूँ और मैंने यह टिप्पणी पोस्ट करने के एक मिनट बाद इस पर ध्यान दिया। मैंने शपथ ली कि जब मैंने अपनी गलती देखी तो उसे हटा दिया, लेकिन किसी तरह, मुझे लगता है कि मैंने ऐसा नहीं किया। उसके लिए माफ़ करना।

— hotshot309

@ कॉफ़ी एडिक्ट क्योंकि पहचानकर्ताओं के भीतर अंडरस्कोर एक <del> विपथन </ del> सी # में वास्तव में मुहावरेदार नहीं है

— Sklivvz

मैं भी उपयोग से बचने के लिए की तरह shouldमैं पसंद करेंगे willतोOrdersWithNoProductsWillFail()

— Calin

@ मेरी राय का उपयोग Willकरना वास्तव में उचित नहीं है और ऐसा करने से आप वास्तव में गलती से पाठक को बता रहे हैं कि किसी भी तरह से परीक्षा में असफल नहीं होगा ... यदि आप Willभविष्य में ऐसा कुछ व्यक्त करने के लिए उपयोग करते हैं जो आप नहीं कर सकते हैं। इसका गलत तरीके से उपयोग करना जबकि Shouldयहां बेहतर विकल्प है क्योंकि यह इंगित करता है कि आप चाहते हैं / कुछ होने की इच्छा है, लेकिन ऐसा नहीं हुआ या नहीं हो सकता है, जब परीक्षण चलता है तो यह बताता है कि क्या यह विफल / सफल रहा ताकि आप वास्तव में इसका मतलब नहीं निकाल सकें। पहले से, कि यह तार्किक व्याख्या है, तुम्हारा क्या है? आप क्यों बचते Shouldहो

— ईयाल सोलनिक

Answer 4

केंट बेक सुझाव देता है:

• 'यूनिट' (आपके कार्यक्रम का वर्ग) प्रति एक परीक्षण स्थिरता। टेस्ट फिक्स्चर स्वयं कक्षाएं हैं। परीक्षण स्थिरता नाम होना चाहिए:

  [name of your 'unit']Tests
  

• परीक्षण मामलों (परीक्षण स्थिरता के तरीकों) के नाम हैं:

  test[feature being tested]
  

उदाहरण के लिए, निम्न वर्ग होना:

class Person {
    int calculateAge() { ... }

    // other methods and properties
}

एक परीक्षण स्थिरता होगी:

class PersonTests {

    testAgeCalculationWithNoBirthDate() { ... }

    // or

    testCalculateAge() { ... }
}

Comments

मैं चाहता हूं कि अधिक लोग इन दिशानिर्देशों का पालन करें। बहुत पहले नहीं, मुझे 20 से अधिक परीक्षा विधियों का नाम बदलना पड़ा क्योंकि उनके पास "एटीस्ट", "बेसिकटेस्ट", या "एररटेस्ट" जैसे नाम थे।

— वेज

क्या 'परीक्षण' की विधि उपसर्ग वर्ग के प्रत्यय को देखते हुए निरर्थक हो जाती है?

— गैविन मिलर

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

— थॉमस जेपरसन

testCalculateAge ... यह आपकी परीक्षण पद्धति का एक अर्थहीन नाम है। "परीक्षण" निरर्थक है (क्या आप "विधि" उपसर्ग के साथ अपने सभी तरीकों का नाम देते हैं?)। बाकी के नाम पर परीक्षण के तहत कोई शर्त नहीं है या क्या उम्मीद थी। गणना की जांच के तहत विधि है? ..... कौन जानता है ...

— 14

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

— siebz0r

Answer 5

कक्षा के नाम । परीक्षण फ़िक्चर नामों के लिए, मुझे पता है कि "परीक्षण" कई डोमेन की सर्वव्यापी भाषा में काफी आम है। उदाहरण के लिए, एक इंजीनियरिंग डोमेन में: StressTestऔर एक सौंदर्य प्रसाधन डोमेन में SkinTest:। केंट से असहमत होने के लिए खेद है, लेकिन मेरे परीक्षण जुड़नार ( StressTestTest?) में "टेस्ट" का उपयोग करना भ्रामक है।

डोमेन में "यूनिट" का भी बहुत उपयोग किया जाता है। जैसे MeasurementUnit। क्या एक वर्ग MeasurementUnitTestको "मापन" या "मापनयुनिट" का परीक्षण कहा जाता है?

इसलिए मैं अपने सभी टेस्ट कक्षाओं के लिए "क्यूए" उपसर्ग का उपयोग करना पसंद करता हूं। जैसे QaSkinTestऔर QaMeasurementUnit। यह डोमेन ऑब्जेक्ट्स के साथ कभी भ्रमित नहीं होता है, और एक प्रत्यय के बजाय एक उपसर्ग का उपयोग करने का मतलब है कि सभी परीक्षण फिक्स्चर नेत्रहीन एक साथ रहते हैं (उपयोगी यदि आपके परीक्षण परियोजना में फेक या अन्य सहायक कक्षाएं हैं)

नाम स्थान । मैं C # में काम करता हूं और मैं अपनी परीक्षा की कक्षाओं को उसी नाम स्थान पर रखता हूं जिस कक्षा में वे परीक्षा दे रहे हैं। यह अलग टेस्ट नेमस्पेस होने से ज्यादा सुविधाजनक है। बेशक, परीक्षण कक्षाएं एक अलग परियोजना में हैं।

परीक्षण विधि के नाम । मैं अपने तरीकों का नाम देना पसंद करता हूं जब एक्सएक्सएक्सएक्स_एक्सपेक्टवाईवाई। यह पूर्व शर्त स्पष्ट करता है, और स्वचालित प्रलेखन (एक ला टेस्टडॉक्स) के साथ मदद करता है। यह Google परीक्षण ब्लॉग पर सलाह के समान है, लेकिन पूर्व शर्त और अपेक्षाओं के अधिक पृथक्करण के साथ। उदाहरण के लिए:

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory

Comments

आपने परीक्षण विधि के नाम और परीक्षण स्थिरता नामों के बारे में बात की। परीक्षण स्थिरता के नाम उत्पादन कक्षाओं में मैप किए जाते हैं। आप अपने परीक्षण में उत्पादन विधि का नाम कहां लिखते हैं?

— द लाइट

Answer 6

मैं दिए गए-जब-तब अवधारणा का उपयोग करता हूं । इस छोटे लेख http://cakebaker.42dh.com/2009/05/28/given-when-then/ पर एक नज़र डालें । आलेख इस अवधारणा का वर्णन BDD के संदर्भ में करता है, लेकिन आप इसे बिना किसी बदलाव के TDD में भी उपयोग कर सकते हैं।

Comments

दिया-जब-तब MethodName_Scenario_ExpectedBehavior के रूप में ही है, है ना ?!

— लाइट

बिल्कुल नहीं। दिया गया_When_Then अधिक संदर्भित करता है: GivenAnEntity_WhenSomeActionHappens_ThatResultIsExpected परीक्षण किसी व्यवहार को लागू करने के लिए इच्छाशक्ति का परीक्षण करना चाहिए ।

— plog17

"गिवेन व्हेन तब" को अक्सर घेरकिन के रूप में संदर्भित किया जाता है। इसका डीएसएल जो ककड़ी, जेहेव और बेहट टूल्स से निकला है।

— बाईटदेव

+1 यह सर्वोत्तम विधि imo है। यह घोषित करना कि एक विधि किस तरह से कुछ करती है जिससे आपको परिणाम की उम्मीद है कि यह बहुत शक्तिशाली है और अन्य टिप्पणियों में वर्णित समस्याओं से बचा जाता है।

— ली

Answer 7

देख: http://googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsibly.html

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

Answer 8

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

Answer 9

मैं हाल ही में अपने परीक्षणों के नामकरण के लिए निम्नलिखित सम्मेलन के साथ आया, उनकी कक्षाओं और उनके विवरणों को अधिकतम करने के लिए परियोजनाएं युक्त:

आइए कहते हैं कि मैं Settingsएक प्रोजेक्ट में MyApp.Serializationनामस्थान में कक्षा का परीक्षण कर रहा हूं ।

पहले मैं MyApp.Serialization.Testsनेमस्पेस के साथ एक टेस्ट प्रोजेक्ट बनाऊंगा।

इस परियोजना के भीतर और निश्चित रूप से नामस्थान मैं एक वर्ग बनाऊंगा जिसे IfSettings( IfSettings.cs के रूप में सहेजा गया है )।

कहते हैं कि मैं SaveStrings()विधि का परीक्षण कर रहा हूं । -> मैं परीक्षण का नाम दूंगा CanSaveStrings()।

जब मैं यह परीक्षण चलाता हूं तो यह निम्नलिखित शीर्षक दिखाएगा:

MyApp.Serialization.Tests.IfSettings.CanSaveStrings

मुझे लगता है कि यह मुझे बहुत अच्छी तरह से बताता है कि यह क्या परीक्षण है।

बेशक यह उपयोगी है कि अंग्रेजी में संज्ञा "टेस्ट" क्रिया "परीक्षण" के समान है।

परीक्षणों के नामकरण में आपकी रचनात्मकता की कोई सीमा नहीं है, ताकि हम उनके लिए पूर्ण वाक्य शीर्षक प्राप्त कर सकें।

आमतौर पर टेस्ट नामों की शुरुआत एक क्रिया से करनी होगी।

उदाहरणों में शामिल:

• पता लगाता है (उदाहरण के लिए DetectsInvalidUserInput)
• फेंकता (जैसे ThrowsOnNotFound)
• विल (जैसे WillCloseTheDatabaseAfterTheTransaction)

आदि।

एक अन्य विकल्प "अगर" के बजाय "कि" का उपयोग करना है।

उत्तरार्द्ध मुझे हालांकि कीस्ट्रोक्स बचाता है और अधिक सटीक रूप से वर्णन करता है कि मैं क्या कर रहा हूं, क्योंकि मुझे नहीं पता है कि परीक्षण किया गया व्यवहार मौजूद है, लेकिन अगर यह है तो परीक्षण कर रहा हूं ।

[ संपादित करें ]

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

इसके अतिरिक्त अब मैं केवल अपने परीक्षण वर्गों में विधियों के लिए उपयोग करता हूं क्योंकि इसे कहीं और सर्वोत्तम अभ्यास नहीं माना जाता है - मेरे परीक्षण विधि नामों में शब्दों को अलग करने के लिए "_":

[Test] public void detects_invalid_User_Input()

मुझे यह पढ़ने में आसान लगता है।

[ अंत संपादित करें ]

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

Answer 10

VS + NUnit में मैं आमतौर पर एक साथ कार्यात्मक परीक्षण करने के लिए अपनी परियोजना में फ़ोल्डर बनाता हूं। फिर मैं यूनिट टेस्ट फिक्सचर क्लासेस बनाता हूं और उन्हें टाइप कर रहा हूं कि मैं किस प्रकार की कार्यक्षमता का परीक्षण कर रहा हूं। [परीक्षण] विधियों की तर्ज पर नाम दिए गए हैं Can_add_user_to_domain:

- MyUnitTestProject   
  + FTPServerTests <- Folder
   + UserManagerTests <- Test Fixture Class
     - Can_add_user_to_domain  <- Test methods
     - Can_delete_user_from_domain
     - Can_reset_password

Answer 11

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

मुझे व्यक्तिगत रूप से "जुनाइट पॉकेट गाइड" में वर्णित सर्वोत्तम अभ्यास पसंद हैं ... जुनीत के सह-लेखक द्वारा लिखी गई पुस्तक को हराना कठिन है!

Comments

विश्वास मत करो यह वास्तव में हाथ में सवाल का जवाब देता है - क्या आप एक संपादन और JUnit पॉकेट गाइड का खंडन कर सकते हैं? धन्यवाद!

— नैट-विल्किंस

Answer 12

कक्षा फू के लिए परीक्षण मामले का नाम FooTestCase होना चाहिए या ऐसा कुछ होना चाहिए (FooIntegrationTestCase या FooAcceptanceTestCase) - चूंकि यह एक परीक्षण मामला है। देखकुछ मानक नामकरण सम्मेलनों जैसे टेस्ट, टेस्ट केस, टेस्ट फिक्सचर, टेस्ट विधि, आदि के लिए http://xunitpatterns.com/ ।