단위 테스트 명명 모범 사례 [닫기]

단위 테스트 클래스 및 테스트 방법의 이름을 지정하는 가장 좋은 방법은 무엇입니까?

이것은 이전에 SO에 대해 논의 되었습니다. 단위 테스트에 대한 인기있는 명명 규칙은 무엇입니까?

이것이 매우 좋은 접근법인지는 모르겠지만 현재 테스트 프로젝트에서 각 프로덕션 클래스와 테스트 클래스 사이에 일대일 매핑이 있습니다 (예 : Product및) ProductTest.

테스트 클래스에는 테스트 할 메소드 이름, 밑줄, 상황 및 예상되는 상황이 포함 된 메소드가 있습니다 (예 :) Save_ShouldThrowExceptionWithNullName().

같은 I 로이 Osherove의 네이밍 전략 , 다음입니다 :

[UnitOfWork_StateUnderTest_ExpectedBehavior]

메소드 이름과 구조화 된 방식에 필요한 모든 정보가 있습니다.

작업 단위는 단일 메소드, 클래스 또는 여러 클래스만큼 작을 수 있습니다. 이 테스트 사례에서 테스트하고 통제 할 모든 사항을 나타내야합니다.

어셈블리의 경우 나는 전형적인 .Tests 끝을 클래스에 대해 매우 광범위하고 동일하다고 생각합니다 Tests.

[NameOfTheClassUnderTestTests]

이전에는 테스트 대신 Fixture를 접미사로 사용했지만 후자가 더 일반적이라고 생각하고 명명 전략을 변경했습니다.

테스트 픽스처의 이름을 지정하는 동안 테스트에 대한 "Should" 이름 지정 표준 을 따르고 싶습니다. 유닛 (예 : 클래스) .

설명하기 (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));
  }
}

왜 "해야" ?

테스트 작성자가 "[일부 상태에있을 때] [후 / 전 / 일] [조치가 수행되어야 함"] 줄에 문장으로 테스트 이름을 지정해야한다는 것을 알게되었습니다.

그렇습니다. "Should"를 어디에나 쓰는 것은 약간 반복적이지만 필자가 말한 것처럼 작가가 올바른 방식으로 생각하도록 강요합니다 (초보자에게는 좋을 수 있습니다). 또한 일반적으로 읽을 수있는 영어 테스트 이름이됩니다.

업데이트 :

나는 지미 Bogard는 '해야'의 팬이기도 한 것으로 나타났습니다 심지어이라는 단위 테스트 라이브러리가 한다는 .

업데이트 (4 년 후 ...)

관심있는 사람들을 위해, 테스트 이름 지정에 대한 나의 접근 방식은 수년에 걸쳐 진화했습니다. 위에서 설명한 should 패턴 의 문제 중 하나는 테스트중인 방법을 한 눈에 알기 쉽지 않은 것으로 설명합니다. OOP의 경우 테스트중인 메소드로 테스트 이름을 시작하는 것이 더 합리적이라고 생각합니다. 잘 설계된 클래스의 경우 읽을 수있는 테스트 메소드 이름이 있어야합니다. 이제와 비슷한 형식을 사용합니다 <method>_Should<expected>_When<condition>. 문맥에 따라 분명히 당신은 should / When 동사를 더 적절한 것으로 대신하고 싶을 것입니다. 예: Deposit_ShouldIncreaseBalance_WhenGivenPositiveValue()

나는이 명명 스타일을 좋아한다 :

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

등등. 테스터가 아닌 사람에게는 문제가 무엇인지 분명하게 알 수 있습니다.

켄트 벡 은 다음과 같이 제안합니다.

• '단위'당 하나의 테스트 픽스처 (프로그램 클래스). 시험 설비는 클래스 자체입니다. 테스트 픽스처 이름은 다음과 같아야합니다.

  [name of your 'unit']Tests
  

• 테스트 케이스 (테스트 픽스처 메소드)의 이름은 다음과 같습니다.

  test[feature being tested]
  

예를 들어 다음과 같은 클래스가 있습니다.

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

    // other methods and properties
}

테스트 픽스처는 다음과 같습니다.

class PersonTests {

    testAgeCalculationWithNoBirthDate() { ... }

    // or

    testCalculateAge() { ... }
}

클래스 이름 . 테스트 픽스처 이름의 경우, "Test"는 많은 도메인의 유비쿼터스 언어에서 매우 일반적입니다. 예를 들어, 엔지니어링 도메인 : StressTest및 화장품 도메인 : SkinTest. Kent에 동의하지 않아서 죄송합니다.하지만 테스트 픽스처에서 "Test"를 사용합니다 (StressTestTest ?) 것은 혼란 스럽습니다.

"단위"는 도메인에서 많이 사용됩니다. 예 MeasurementUnit. 라는 클래스입니다MeasurementUnitTest"Measurement"또는 "MeasurementUnit"의 테스트 입니까?

따라서 모든 테스트 클래스에 "Qa"접두사를 사용하고 싶습니다. 예 QaSkinTest를 들어QaMeasurementUnit . 도메인 객체와 혼동되지 않으며 접미사 대신 접두사를 사용하면 모든 테스트 픽스처가 시각적으로 함께 존재한다는 것을 의미합니다 (테스트 프로젝트에 가짜 또는 다른 지원 클래스가있는 경우 유용합니다)

네임 스페이스 . C #에서 일하고 테스트 클래스와 동일한 네임 스페이스에 테스트 클래스를 유지합니다. 별도의 테스트 네임 스페이스를 사용하는 것보다 편리합니다. 물론 테스트 수업은 다른 프로젝트에 있습니다.

테스트 방법 이름 . 메소드 이름을 WhenXXX_ExpectYYY로 지정하고 싶습니다. 사전 조건을 명확하게하고 자동화 된 문서 (La TestDox)를 도와줍니다. 이는 Google 테스트 블로그의 조언과 유사하지만 전제 조건과 기대치가 더 분리되어 있습니다. 예를 들면 다음과 같습니다.

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory

나는 사용하십시오 감안할 - - 그런 때 개념. 이 짧은 기사 http://cakebaker.42dh.com/2009/05/28/given-when-then/을 살펴보십시오 . 기사에서는이 개념을 BDD 측면에서 설명하지만 변경없이 TDD에서도 사용할 수 있습니다.

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

테스트 메소드 이름의 경우 개인적으로 상세하고 자체 문서화 된 이름을 사용하는 것이 매우 유용합니다 (테스트가 수행중인 작업을 추가로 설명하는 Javadoc 주석과 함께).

가장 중요한 것 중 하나는 네이밍 컨벤션에서 일관성이 있다고 생각합니다 (그리고 팀의 다른 멤버들과 동의합니다). 여러 번 같은 프로젝트에 사용 된 다양한 규칙이 있습니다.

나는 최근에 설명을 극대화하기 위해 테스트, 클래스 및 프로젝트를 명명하는 다음과 같은 규칙을 생각해 냈습니다.

네임 스페이스 Settings의 프로젝트에서 클래스를 테스트한다고 가정 해 MyApp.Serialization보겠습니다.

먼저 MyApp.Serialization.Tests네임 스페이스를 사용하여 테스트 프로젝트를 만듭니다 .

이 프로젝트와 물론 네임 스페이스에서 IfSettings( IfSettings.cs로 저장 됨 ) 라는 클래스를 만듭니다 .

SaveStrings()방법을 테스트한다고 가정 해 봅시다 . -> 테스트 이름을 지정합니다 CanSaveStrings().

이 테스트를 실행하면 다음과 같은 제목이 표시됩니다.

MyApp.Serialization.Tests.IfSettings.CanSaveStrings

나는 이것이 테스트하고있는 것을 나에게 잘 알려 준다고 생각한다.

물론 영어에서 명사 "Tests"는 동사 "tests"와 같은 것이 유용합니다.

시험의 이름을 정할 때 창의력에는 제한이 없으므로 시험에 대한 완전한 문장 제목을 얻습니다.

일반적으로 테스트 이름은 동사로 시작해야합니다.

예를 들면 다음과 같습니다.

• 감지 (예 DetectsInvalidUserInput)
• 예외 (예 ThrowsOnNotFound)
• 윌 (예 WillCloseTheDatabaseAfterTheTransaction)

기타

다른 옵션은 "if"대신 "that"을 사용하는 것입니다.

후자는 나를 불구하고 키 입력과 내가 알고하지 않기 때문에, 뭐하는 거지 더 정확히 설명 저장 하는 테스트 동작이 존재하지만 테스트입니다 경우 가 있습니다.

[ 편집 ]

위의 명명 규칙을 조금 더 오래 사용한 후에 인터페이스를 사용할 때 If 접두사가 혼동 될 수 있음 을 알았습니다 . 테스트 클래스 IfSerializer.cs 는 "파일 열기 탭"의 ISerializer.cs 인터페이스와 매우 유사하게 나타납니다 . 이것은 테스트, 테스트중인 클래스 및 인터페이스 사이를 전환 할 때 매우 성 가실 수 있습니다. 결과적으로 접두사로 That over If 를 선택 합니다.

또한 이제 다른 곳에서는 모범 사례로 간주되지 않으므로 테스트 클래스의 메소드에만 사용합니다. 테스트 메소드 이름에서 단어를 다음과 같이 구분하는 "_":

[Test] public void detects_invalid_User_Input()

나는 이것을 더 읽기 쉽다는 것을 안다.

[ 편집 종료 ]

테스트가 무엇을하고 있는지 이해하는 데 많은 시간을 절약 할 수 있기 때문에 중요한 이름 지정 테스트를 고려하기 때문에 이것이 더 많은 아이디어를 낳기를 바랍니다. .

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

테스트를 동일한 패키지에 보관하지만 테스트 대상 소스의 병렬 디렉토리에 유지하면 많은 제외 패턴을 수행하지 않고 코드를 배포 할 준비가되면 코드의 부풀림이 제거됩니다.

저는 개인적으로 "JUnit Pocket Guide"에 설명 된 모범 사례를 좋아합니다. JUnit 의 공동 저자가 쓴 책을이기는 것은 어렵습니다!

Foo 클래스의 테스트 케이스 이름은 FooTestCase 또는 이와 유사한 이름 (FooIntegrationTestCase 또는 FooAcceptanceTestCase)이어야합니다. 테스트 케이스이기 때문입니다. 테스트, 테스트 케이스, 테스트 픽스처, 테스트 방법 등과 같은 일부 표준 명명 규칙 은 http://xunitpatterns.com/ 을 참조하십시오 .