การทดสอบการตั้งชื่อหน่วยการปฏิบัติที่ดีที่สุด [ปิด]

564

ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังว่าคำตอบจะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการอภิปรายโต้แย้งโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ

ปิดให้บริการใน7 ปีที่ผ่านมา

แนวปฏิบัติที่ดีที่สุดสำหรับการตั้งชื่อคลาสการทดสอบหน่วยและวิธีการทดสอบคืออะไร

สิ่งนี้ถูกพูดถึงใน SO ก่อนหน้านี้ที่อนุสัญญาการตั้งชื่อยอดนิยมสำหรับการทดสอบหน่วยมีอะไรบ้าง

ผมไม่ทราบว่านี้เป็นวิธีการที่ดีมาก แต่ในปัจจุบันโครงการการทดสอบของฉันฉันมีแมปแบบหนึ่งต่อหนึ่งระหว่างแต่ละระดับการผลิตและการทดสอบระดับเช่นและProductProductTest

Save_ShouldThrowExceptionWithNullName()ในการเรียนการทดสอบของฉันฉันก็มีวิธีการที่มีชื่อของวิธีการที่ฉันกำลังทดสอบขีดล่างและจากนั้นสถานการณ์และสิ่งที่ผมคาดหวังว่าจะเกิดขึ้นเช่น

unit-testing naming-conventions

— James Newton-King
แหล่งที่มา

ดูที่นี่: stackoverflow.com/questions/96297/…

— Semicolon ที่ลืม

1

สิ่งนี้ไม่ตอบคำถามของคุณ แต่ควรอ่าน: haacked.com/archive/2012/01/02/structuring-unit-tests.aspx

— Robs

3

คู่มือสไตล์ Google พูดว่า: test<MethodUnderTest>_<state>เช่นtestPop_emptyStack google-styleguide.googlecode.com/svn/trunk/javaguide.html 5.2.3 ชื่อวิธี หากมีข้อสงสัยให้ติดตาม Google

— Ciro Santilli 法轮功冠状病六四事件法轮功

2

@CiroSantilli 六四事件法轮功包卓轩และประโยคต่อไปบอกว่า: "ไม่มีวิธีแก้ไขชื่อวิธีการทดสอบที่ถูกต้อง" ไปคิด

— user2418306

1

ฉันยังคงชอบคำแนะนำของ Phil Haack แม้กระทั่งหลายปีต่อมา

— pimbrouwers

524

ฉันชอบกลยุทธ์การตั้งชื่อของ Roy Osheroveมันเป็นดังต่อไปนี้:

[UnitOfWork_StateUnderTest_ExpectedBehavior]

มันมีข้อมูลทุกอย่างที่จำเป็นในชื่อวิธีการและในลักษณะที่มีโครงสร้าง

หน่วยของงานอาจมีขนาดเล็กเป็นวิธีการเดียวชั้นเรียนหรือใหญ่เป็นหลายชั้นเรียน ควรแสดงทุกสิ่งที่จะต้องทดสอบในกรณีทดสอบนี้และอยู่ภายใต้การควบคุม

สำหรับแอสเซมบลีฉันใช้.Testsตอนจบทั่วไปซึ่งฉันคิดว่าค่อนข้างแพร่หลายและเหมือนกันสำหรับคลาส (ลงท้ายด้วยTests):

[NameOfTheClassUnderTestTests]

ก่อนหน้านี้ฉันใช้ Fixture เป็นคำต่อท้ายแทนการทดสอบ แต่ฉันคิดว่าอันหลังเป็นเรื่องธรรมดามากขึ้นจากนั้นฉันเปลี่ยนกลยุทธ์การตั้งชื่อ

— Marc Climent
แหล่งที่มา

228

สำหรับฉันมันไม่มีเหตุผลที่จะใส่ชื่อวิธีการในวิธีการทดสอบ ถ้าคุณเปลี่ยนวิธีการ ไม่มีเครื่องมือ refactoring จะเปลี่ยนชื่อการทดสอบสำหรับคุณ ในที่สุดคุณจะสิ้นสุดการเปลี่ยนชื่อวิธีทดสอบด้วยมือหรือมีแนวโน้มที่จะมีการทดสอบผิดชื่อ มันเหมือนกับความคิดเห็น มากไปกว่านั้นก็ไม่ได้แสดงความคิดเห็นรหัสเลย

— Piotr Perak

80

@ เปรีฉันคิดว่ามันเป็นการแลกเปลี่ยน ในอีกด้านหนึ่งชื่อการทดสอบของคุณอาจล้าสมัยในทางกลับกันคุณไม่สามารถบอกได้ว่าวิธีการทดสอบของคุณกำลังทดสอบอะไร ฉันพบว่าหลังเกิดขึ้นบ่อยครั้งมากขึ้น

— Joel McBeth

15

เพื่อเพิ่มความคิดเห็นเปริ - UpdateManager.Update()วิธีการทั้งหมดมีความรับผิดชอบในการกระทำบางอย่างเช่น มีในใจฉันมักจะเรียกการทดสอบของฉันหรือWhenUpdating_State_Behaviour WhenUpdating_Behaviour_Stateวิธีนี้ฉันจะทดสอบการกระทำเฉพาะของคลาสโดยหลีกเลี่ยงการใส่ชื่อเมธอดในชื่อการทดสอบ แต่สิ่งที่สำคัญที่สุดคือฉันต้องรู้ว่าตรรกะทางธุรกิจล้มเหลวเมื่อฉันเห็นชื่อของการทดสอบที่ล้มเหลว

— Ramunas

8

Resharper และ IntelliJ ทั้งคู่อาจพบวิธีทดสอบของคุณและเสนอให้เปลี่ยนชื่อให้คุณหากคุณปรับเปลี่ยน / เปลี่ยนชื่อใหม่โดยใช้เครื่องมือเหล่านั้น ความพยายามที่จะมองในความคิดเห็นที่คุณพูดถึงชื่อวิธีการและปรับปรุงเหล่านั้นด้วย

— Jeff Martin

62

ชื่อวิธีการที่ดีมักจะเหมือนกับการดำเนินการของวิธีการที่สมบูรณ์ หากคุณต้องตัดสินใจระหว่างการตั้งชื่อการทดสอบของคุณหลังจากที่วิธีการหรือการกระทำของคุณมีประสิทธิภาพวิธีการที่อาจจะมีคำใบ้ที่คุณควรเปลี่ยนชื่อวิธีการของคุณ (ไม่ใช่ในทุกกรณี)

— Kaadzia

121

ฉันชอบที่จะปฏิบัติตามมาตรฐานการตั้งชื่อ"ควร"สำหรับการทดสอบในขณะที่ตั้งชื่อฟิกซ์เจอร์ทดสอบหลังจากหน่วยที่อยู่ภายใต้การทดสอบ (เช่นคลาส)

ตัวอย่าง (ใช้ 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));
  }
}

ทำไม"ควร" ?

ฉันพบว่ามันบังคับให้ผู้เขียนทดสอบตั้งชื่อการทดสอบด้วยประโยคตามแนวของ "ควร [อยู่ในบางสถานะ] [หลังจาก / ก่อน / เมื่อ /]] [การกระทำเกิดขึ้น]"

ใช่การเขียนว่า "ควร" ทุกที่จะได้รับการทำซ้ำเล็กน้อย แต่อย่างที่ฉันบอกว่ามันบังคับให้นักเขียนคิดในทางที่ถูกต้อง รวมทั้งโดยทั่วไปแล้วจะส่งผลให้ชื่อการทดสอบภาษาอังกฤษที่สามารถอ่านได้

ปรับปรุง :

ฉันสังเกตเห็นว่า Jimmy Bogard เป็นแฟนของ 'ควร' และยังมีห้องสมุดทดสอบหน่วยที่เรียกว่าควรควร

อัปเดต (4 ปีต่อมา ... )

สำหรับผู้ที่สนใจวิธีการทดสอบการตั้งชื่อของฉันมีวิวัฒนาการมาหลายปีแล้ว หนึ่งในปัญหาที่มีรูปแบบควรฉันอธิบายข้างต้นเป็นมันไม่ง่ายที่จะรู้ได้อย่างรวดเร็วซึ่งวิธีการที่อยู่ภายใต้การทดสอบ สำหรับ OOP ฉันคิดว่าเหมาะสมกว่าที่จะเริ่มต้นชื่อการทดสอบด้วยวิธีการทดสอบ สำหรับคลาสที่ออกแบบมาอย่างดีควรทำให้ชื่อวิธีทดสอบอ่านได้ <method>_Should<expected>_When<condition>ตอนนี้ผมใช้รูปแบบคล้ายกับ เห็นได้ชัดว่าขึ้นอยู่กับบริบทที่คุณอาจต้องการแทนคำกริยา Should / When สำหรับสิ่งที่เหมาะสมกว่า ตัวอย่าง: Deposit_ShouldIncreaseBalance_WhenGivenPositiveValue()

— Jack Ukleja
แหล่งที่มา

32

increasesBalanceWhenDepositIsMade()แม้อาจจะดีขึ้นและซ้ำซ้อนน้อยเพียงเขียนประโยคที่บอกว่าสิ่งที่มันไม่สมมติว่าผลงานการทดสอบ:

— hotshot309

3

เพิ่งเห็นบทความที่กล่าวถึงรูปแบบการตั้งชื่อที่คล้ายกัน (หวังว่าฉันจะบุ๊คมาร์คไว้) ออกแบบมาเพื่อทำให้รายการของการทดสอบสามารถอ่านได้มากเมื่อเรียงลำดับตามฟิกซ์เจอร์ทดสอบ คุณเห็นบางอย่างเช่น "BankAccount" จากนั้นภายใต้ (ในบรรทัดที่แตกต่างกัน) "Should_Increase_Balance_When_Deposit_Is_Made" "Should_Decrease_Balance_When_Withdrawal_Is_Made" เป็นสิ่งที่คล้ายกันมาก

— Simon Tewsi

พบบทความ มันอยู่ในจัสติน Etheredge ของ CodeThinked บล็อกเริ่มต้นด้วยการเยาะเย้ยขั้นต่ำ 3 - Part 1

— Simon Tewsi

11

ฉันยังใช้ควรและเมื่อ แต่วิธีอื่น ๆ รอบ เช่น WhenCustomerDoesNotExist_ShouldThrowException () สำหรับฉันแล้วสิ่งนี้มีเหตุผลมากกว่าที่ควรในเมื่อ (เช่นในบางสถานการณ์ควรมีผลลัพธ์ที่คาดหวังไว้) นอกจากนี้ยังสอดคล้องกับ AAA (Arrange, Actert Assert) ... Assert คือจุดจบ ... ไม่ใช่จุดเริ่มต้น ;-)

— bytedev

2

@Schneider: พิจารณา "ควร" = "แนะนำ" แล้วตัวเลือกฉันสงสัย: มันจะไม่ดีกว่าการใช้คำศัพท์ "จะ" = "ต้อง" แล้วต้อง / จำเป็น ตัวอย่างเช่น RFCs สร้างความแตกต่างระหว่างทั้งสอง ดังนั้นควรมีการแนะนำหรือผ่านการทดสอบ?

— blackwizard

79

ฉันชอบสไตล์การตั้งชื่อนี้:

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

และอื่น ๆ มันทำให้ชัดเจนกับผู้ที่ไม่ใช่ผู้ทดสอบว่าปัญหาคืออะไร

— Sklivvz
แหล่งที่มา

63

แต่ @ hotshot309 เขาอาจใช้. NET - . NET Capitalization Conventions

— Ace

2

@ ตอนนี้ฉันเห็นด้วยกับคุณโดยสิ้นเชิงและสังเกตเห็นสิ่งนี้ประมาณหนึ่งนาทีหลังจากที่ฉันโพสต์ความคิดเห็นนี้ ฉันสาบานว่าฉันลบมันเมื่อฉันเห็นความผิดพลาด แต่อย่างใดฉันคิดว่าฉันไม่ได้ ขอโทษด้วยกับเรื่องนั้น.

— hotshot309

3

@CoffeeAddict เนื่องจากการขีดเส้นใต้ภายในตัวระบุเป็นความผิดปกติ <del> </del> ไม่ใช่เรื่องจริงใน C #

— Sklivvz

2

ฉันยังต้องการหลีกเลี่ยงการใช้งานที่shouldฉันต้องการwillมากกว่านี้OrdersWithNoProductsWillFail()

— Calin

4

@Calin ในความคิดของฉันใช้Willไม่เหมาะสมจริง ๆและโดยการทำเช่นนั้นจริง ๆ แล้วคุณผิดบอกผู้อ่านว่าไม่มีวิธีการทดสอบจะล้มเหลว ... ถ้าคุณใช้Willเพื่อแสดงบางสิ่งบางอย่างในอนาคตที่อาจไม่เกิดขึ้นคุณ ใช้มันอย่างไม่ถูกต้องในขณะที่Shouldเป็นตัวเลือกที่ดีกว่าที่นี่เพราะมันบ่งบอกว่าคุณต้องการ / ต้องการบางสิ่งบางอย่างเกิดขึ้น แต่มันไม่ได้หรือไม่สามารถทำได้เมื่อการทดสอบรันมันจะบอกคุณว่ามันล้มเหลว / ประสบความสำเร็จ ก่อนหน้านี้นั่นคือคำอธิบายที่สมเหตุสมผลสำหรับคุณคุณเป็นใคร? ทำไมคุณหลีกเลี่ยงShould?

— Eyal Solnik

51

Kent Beckแนะนำ:

หนึ่งฟิกซ์เจอร์ทดสอบต่อ 'หน่วย' (คลาสของโปรแกรมของคุณ) การทดสอบการเรียนเป็นตัวเอง ชื่อฟิกซ์เจอร์ทดสอบควรเป็น:
```
[name of your 'unit']Tests
```
กรณีทดสอบ (วิธีการติดตั้งการทดสอบ) มีชื่อเช่น:
```
test[feature being tested]
```

ตัวอย่างเช่นมีคลาสต่อไปนี้:

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

    // other methods and properties
}

การติดตั้งการทดสอบจะเป็น:

class PersonTests {

    testAgeCalculationWithNoBirthDate() { ... }

    // or

    testCalculateAge() { ... }
}

— Sergio Acosta
แหล่งที่มา

4

ฉันหวังว่าผู้คนจำนวนมากจะทำตามแนวทางเหล่านี้ ไม่นานมานี้ฉันต้องเปลี่ยนชื่อมากกว่า 20 วิธีการทดสอบเพราะพวกเขามีชื่อเช่น "ATest", "BasicTest" หรือ "ErrorTest"

— ลิ่ม

85

คำนำหน้าวิธีการ 'ทดสอบ' ไม่ซ้ำซ้อนเนื่องจากส่วนต่อท้ายของชั้นเรียนหรือไม่

— Gavin Miller

50

จำไว้ว่าเมื่อเคนเขียนหนังสือเล่มนั้น ไม่มีการประดิษฐ์คุณสมบัติ ดังนั้นชื่อ Test ในชื่อเมธอดที่ระบุในเฟรมเวิร์กการทดสอบว่าเมธอดเป็นการทดสอบ ยังมีความสุขอีกมากมายตั้งแต่ปี 2002

— Thomas Jespersen

14

testCalculateAge ... นี่เป็นชื่อที่ไม่มีความหมายสำหรับวิธีการทดสอบของคุณ "test" ซ้ำซ้อน (คุณตั้งชื่อวิธีการทั้งหมดด้วยคำนำหน้า "method" หรือไม่) ส่วนที่เหลือของชื่อไม่มีเงื่อนไขภายใต้การทดสอบหรือสิ่งที่คาดหวัง CalculateAge เป็นวิธีการภายใต้การทดสอบ ..... ใครจะรู้ ... ?

— bytedev

1

ฉันต้องการเพิ่มว่าเมื่อใช้กลยุทธ์นี้จำเป็นต้องมีเอกสารประกอบเพื่อระบุผลลัพธ์ที่ต้องการ ในฐานะที่เป็นบันทึกด้านข้างเกี่ยวกับคำนำหน้า 'ทดสอบ'; เฟรมเวิร์กการทดสอบบางยูนิตต้องการคำนำหน้าหรือคำต่อท้ายเฉพาะเพื่อจดจำการทดสอบ คำนำหน้าคลาสนามธรรมด้วย 'บทคัดย่อ' ไม่ถือว่าซ้ำซ้อน (เพราะเป็นเอกสารด้วยตนเอง) ดังนั้นทำไมจึงไม่เหมือนกันกับ 'ทดสอบ'

— siebz0r

17

ชื่อชั้น สำหรับชื่อฟิกซ์เจอร์ทดสอบฉันพบว่า "การทดสอบ" เป็นเรื่องปกติในภาษาที่แพร่หลายในหลาย ๆ โดเมน ยกตัวอย่างเช่นในโดเมนวิศวกรรม: และในโดเมนเครื่องสำอาง:StressTest SkinTestขออภัยที่ไม่เห็นด้วยกับ Kent แต่การใช้ "การทดสอบ" ในการทดสอบการทดสอบของฉัน ( StressTestTest?) นั้นทำให้เกิดความสับสน

"หน่วย" ยังใช้มากในโดเมน MeasurementUnitเช่น คลาสเรียกว่าMeasurementUnitTestการทดสอบ "การวัด" หรือ "การวัดหน่วย" หรือไม่?

ดังนั้นฉันชอบที่จะใช้คำนำหน้า "Qa" สำหรับชั้นเรียนทดสอบของฉันทั้งหมด เช่นและQaSkinTest QaMeasurementUnitมันไม่เคยสับสนกับวัตถุโดเมนและการใช้คำนำหน้าแทนส่วนต่อท้ายหมายความว่าการทดสอบทั้งหมดอาศัยอยู่ด้วยกันมองเห็น (มีประโยชน์ถ้าคุณมี fakes หรือชั้นเรียนสนับสนุนอื่น ๆ ในโครงการทดสอบของคุณ)

namespaces ฉันทำงานใน C # และฉันเก็บคลาสการทดสอบของฉันในเนมสเปซเดียวกันกับคลาสที่พวกเขากำลังทดสอบ สะดวกกว่าการมีเนมสเปซทดสอบแยกต่างหาก แน่นอนว่าคลาสการทดสอบอยู่ในโครงการอื่น

ชื่อวิธีการทดสอบ ฉันต้องการตั้งชื่อวิธีการของฉันเมื่อ XXXX_ExpectYYY มันทำให้เงื่อนไขชัดเจนและช่วยด้วยเอกสารอัตโนมัติ (a la TestDox) สิ่งนี้คล้ายกับคำแนะนำในบล็อกการทดสอบของ Google แต่มีเงื่อนไขและความคาดหวังแยกกันมากขึ้น ตัวอย่างเช่น:

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory

— grundoon
แหล่งที่มา

คุณได้พูดถึงชื่อวิธีทดสอบและชื่อชุดทดสอบ ชื่อฟิกซ์เจอร์ทดสอบถูกแม็พกับคลาสการผลิต คุณเขียนชื่อวิธีการผลิตในการทดสอบที่ไหน

— แสงสว่าง

12

ฉันใช้แนวคิดGiven-When-Then ลองดูที่บทความสั้น ๆ นี้http://cakebaker.42dh.com/2009/05/28/given-when-then/ บทความอธิบายแนวคิดนี้ในแง่ของ BDD แต่คุณสามารถใช้มันใน TDD ได้เช่นกันโดยไม่มีการเปลี่ยนแปลงใด ๆ

— Pashec
แหล่งที่มา

ป.ร. ให้ไว้เมื่อ - จากนั้นเป็นเช่นเดียวกับ MethodName_Scenario_ExpectedBehavior ไม่ได้หรือไม่!

— แสงสว่าง

1

ไม่แน่นอน Given_When_Then หมายมากขึ้น: GivenAnEntity_WhenSomeActionHappens_ThatResultIsExpected การทดสอบควรแสดงจะทดสอบพฤติกรรมไม่ได้ดำเนินการ

— plog17

1

"เมื่อไหร่" มักถูกอ้างถึงว่าเป็น Gherkin มันเป็น DSL ที่มาจากเครื่องมือแตงกวา, JBehave และ Behat

— bytedev

+1 นี่คือวิธีที่ดีที่สุด imo Decoupling ว่าวิธีการทำอะไรบางอย่างจากสิ่งที่คุณคาดหวังว่าผลลัพธ์จะมีประสิทธิภาพมากและหลีกเลี่ยงปัญหามากมายที่อธิบายไว้ในความคิดเห็นอื่น ๆ

— Lee

8

ดู: http://googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsibly.html

สำหรับชื่อเมธอดการทดสอบฉันพบว่าการใช้ชื่อ verbose และชื่อที่บันทึกด้วยตนเองนั้นมีประโยชน์มาก

— Ates Goral
แหล่งที่มา

7

ฉันคิดว่าหนึ่งในสิ่งที่สำคัญที่สุดมีความสอดคล้องในแบบแผนการตั้งชื่อของคุณ (และเห็นด้วยกับสมาชิกคนอื่น ๆ ในทีมของคุณ) หลายครั้งที่ฉันเห็นการประชุมที่แตกต่างกันจำนวนมากที่ใช้ในโครงการเดียวกัน

— bytedev
แหล่งที่มา

7

ฉันเพิ่งมากับการประชุมต่อไปนี้สำหรับการตั้งชื่อการทดสอบของฉันชั้นเรียนของพวกเขาและมีโครงการเพื่อเพิ่ม descriptivenes ของพวกเขา:

ให้บอกว่าฉันกำลังทดสอบSettingsชั้นเรียนในโครงการในMyApp.Serializationnamespace

ก่อนอื่นฉันจะสร้างโครงการทดสอบด้วยMyApp.Serialization.Testsเนมสเปซ

ภายในโครงการนี้และแน่นอนเนมสเปซฉันจะสร้างคลาสที่เรียกว่าIfSettings(บันทึกเป็นIfSettings.cs )

ให้บอกว่าฉันกำลังทดสอบSaveStrings()วิธี -> CanSaveStrings()ฉันจะตั้งชื่อการทดสอบ

เมื่อฉันรันการทดสอบนี้มันจะแสดงหัวข้อดังต่อไปนี้:

MyApp.Serialization.Tests.IfSettings.CanSaveStrings

ฉันคิดว่าสิ่งนี้บอกฉันได้ดีมากว่ามันคืออะไรการทดสอบ

แน่นอนว่ามันมีประโยชน์ว่าในภาษาอังกฤษคำนาม "การทดสอบ" เหมือนกับคำกริยา "การทดสอบ"

ความคิดสร้างสรรค์ของคุณไม่มีข้อ จำกัด ในการตั้งชื่อการทดสอบเพื่อให้เราได้รับส่วนหัวที่สมบูรณ์สำหรับพวกเขา

โดยปกติชื่อการทดสอบจะต้องเริ่มต้นด้วยคำกริยา

ตัวอย่างรวมถึง:

ตรวจจับ (เช่นDetectsInvalidUserInput)
พ่น (เช่นThrowsOnNotFound)
จะ (เช่นWillCloseTheDatabaseAfterTheTransaction)

เป็นต้น

ตัวเลือกอื่นคือการใช้ "ว่า" แทนที่จะเป็น "ถ้า"

อันหลังช่วยให้ฉันกดแป้นได้แม้ว่าและอธิบายเพิ่มเติมสิ่งที่ฉันกำลังทำอยู่เพราะฉันไม่รู้ว่าพฤติกรรมที่ทดสอบนั้นมีอยู่ แต่กำลังทดสอบว่ามันเป็นเช่นไร

[ แก้ไข ]

หลังจากใช้แบบแผนการตั้งชื่อข้างต้นนานขึ้นเล็กน้อยฉันพบว่าคำนำหน้าIfอาจสับสนเมื่อทำงานกับส่วนต่อประสาน มันเกิดขึ้นอย่างนั้นคลาสการทดสอบIfSerializer.csดูคล้ายกับอินเตอร์เฟสISerializer.csใน "Open Files Tab" สิ่งนี้จะทำให้เกิดความรำคาญเมื่อสลับไปมาระหว่างการทดสอบคลาสที่ทดสอบและอินเทอร์เฟซ ดังนั้นตอนนี้ฉันจะเลือกว่ามากกว่าถ้าเป็นคำนำหน้า

นอกจากนี้ตอนนี้ฉันใช้ - เฉพาะสำหรับวิธีการในชั้นเรียนทดสอบของฉันเพราะมันไม่ถือว่าเป็นแนวปฏิบัติที่ดีที่สุดที่อื่น - "_" เพื่อแยกคำในชื่อวิธีการทดสอบของฉันเช่นเดียวกับใน:

[Test] public void detects_invalid_User_Input()

ฉันพบว่ามันอ่านง่ายกว่า

[ สิ้นสุดการแก้ไข ]

ฉันหวังว่าสิ่งนี้จะวางแนวความคิดเพิ่มเติมเนื่องจากฉันคิดว่าการตั้งชื่อการทดสอบมีความสำคัญอย่างยิ่งเนื่องจากจะช่วยให้คุณประหยัดเวลาได้มากที่จะใช้เวลาพยายามทำความเข้าใจว่าการทดสอบกำลังทำอะไร (เช่นหลังจากกลับมาทำโครงการอีกครั้ง .

— Thorsten Lorenz
แหล่งที่มา

2

ใน VS + NUnit ฉันมักจะสร้างโฟลเดอร์ในโครงการของฉันเพื่อจัดกลุ่มการทดสอบการทำงานร่วมกัน จากนั้นฉันจะสร้างคลาสฟิกซ์เจอร์ทดสอบหน่วยและตั้งชื่อตามประเภทของฟังก์ชั่นที่ฉันกำลังทดสอบ [Test] วิธีการตั้งชื่อตามแนวของ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

— Kev
แหล่งที่มา

2

ฉันควรเพิ่มว่าการเก็บการทดสอบของคุณในแพ็คเกจเดียวกัน แต่ในไดเรคทอรีขนานไปกับซอร์สที่ถูกทดสอบจะกำจัดการขยายตัวของโค้ดเมื่อคุณพร้อมที่จะนำไปใช้งานโดยไม่ต้องทำรูปแบบอื่น ๆ

ฉันชอบแนวปฏิบัติที่ดีที่สุดที่อธิบายไว้ใน"JUnit Pocket Guide" ... มันยากที่จะเอาชนะหนังสือที่เขียนโดยผู้เขียนร่วมของ JUnit!

— Steve Moyer
แหล่งที่มา

3

อย่าเชื่อว่าสิ่งนี้ตอบคำถามได้จริง - คุณสามารถแก้ไขและอ้างอิง JUnit Pocket Guide ได้หรือไม่ ขอบคุณ!

— Nate-Wilkins

0

ชื่อของกรณีทดสอบสำหรับคลาส Foo ควรเป็น FooTestCase หรือชื่ออื่น (FooIntegrationTestCase หรือ FooAcceptanceTestCase) - เนื่องจากเป็นกรณีทดสอบ ดูhttp://xunitpatterns.com/สำหรับข้อตกลงการตั้งชื่อมาตรฐานเช่นการทดสอบกรณีทดสอบการติดตั้งการทดสอบวิธีการทดสอบ ฯลฯ