단위 테스트의 명명 규칙을 변경해야합니까?

StackOverflow https://stackoverflow.com/questions/1018525

문제

나는 현재 단위 테스트를 위해 간단한 컨벤션을 사용하고 있습니다. "EmployeEreader"라는 클래스가있는 경우 "EmployeEreader.tests라는 테스트 클래스를 만듭니다. 그런 다음 테스트 클래스의 클래스에 대한 모든 테스트를 다음과 같은 이름으로 만듭니다.

  • reading_valid_employee_data_correctely_generates_employee_object
  • reading_missing_employee_data_throws_invalid_employee_id_exception

등등.

나는 최근에 A에 대해 읽고있다 다른 유형의 명명 규칙 BDD에서 사용됩니다. 나는이 명명의 가독성을 좋아하고 다음과 같은 테스트 목록으로 끝납니다.

  • when_reading_valid_employee (fixture)
    • Employee_object_is_generated (메소드)
    • Employee_HAS_CORRECT_ID (메소드)
  • when_reading_missing_employee (Fixture)
    • an_invalid_employee_id_exception_is_thrown (method)

등등.

두 스타일의 명명을 사용한 사람이 있습니까? 다음 프로젝트의 전환 여부를 결정하는 데 도움이되는 조언, 혜택, 단점, Gotchas 등을 제공 할 수 있습니까?

도움이 되었습니까?

해결책

두 번째 예제 (각 클래스마다 하나가 아닌 각 논리적 "작업"에 대한 고정 장치가있는 경우 각 작업마다 다른 설정 및 찢어짐 논리를 가질 수 있으므로 개별 테스트 방법을 단순화하고 더 읽기 쉬운 이점이 있습니다.

하나 또는 다른 하나를 표준으로 정산 할 필요는 없습니다. 우리는 각 클래스에 대해 테스트 해야하는 다른 "작업"수에 따라 두 가지 혼합물을 사용합니다.

다른 팁

내가 사용한 이름 지정 규칙은 다음과 같습니다.

functionname_shoulddothis_whenthisisTesituation

예를 들어, 이들은 스택의 '팝'기능에 대한 일부 테스트 이름입니다.

pop_shouldthrowemptystackexception_whenthestackisempty

POP_SHOULDERTERNTHEOBJECTONTHETOPOFTSCOFOFTACK_WHETHENSEREISANOBJECTONTHESTACK

긴 줄이 코드를 읽기가 더 어려워 지거나 탈지기가 더 어려워지면서 단위 테스트를 다른 사람에게 더 읽기 쉽게 만들기 때문에 두 번째는 더 나은 느낌이 듭니다. 테스트가하는 일에 대한 모호성이 여전히 있다고 생각되면이를 명확히하기 위해 의견을 추가 할 수 있습니다.

당신이 참조하는 2 차 명명 컨벤션의 배후에 대한 추론의 일부는 당신이 동시에 테스트 및 행동 사양을 만들고 있다는 것입니다. 당신은 일이 일어나고있는 맥락과 그 맥락에서 실제로 일어날 일을 확립합니다. (내 경험상, 관찰/테스트-메토드는 종종 "dilt_"로 시작하므로 표준을 얻을 수 있습니다.

테스트 비품을 반영하고 밑줄을 벗겨 내고 밑줄을 제거하는 멋진 HTML 사양 시트를 출력하는 도구가 있습니다. 실제 코드와 동기화되는 사람이 읽을 수있는 문서로 끝납니다 (테스트 범위를 높고 정확하게 유지하는 한).

작업중인 스토리/기능/하위 시스템에 따라 이러한 사양은 비 프로그램 제 이해 관계자가 특히 민첩한 및 BDD의 핵심 인 검증 및 피드백을 위해 보여지고 이해할 수 있습니다.

두 번째 방법을 사용하며 소프트웨어가 수행해야 할 작업을 설명하는 데 실제로 도움이됩니다. 또한 중첩 클래스를 사용하여보다 자세한 컨텍스트를 설명합니다.

본질적으로 테스트 클래스는 컨텍스트이며 중첩 될 수 있으며 방법은 모두 한 줄의 주장입니다. 예를 들어,

public class MyClassSpecification
{
    protected MyClass instance = new MyClass();

    public class When_foobar_is_42 : MyClassSpecification 
    {
        public When_foobar_is_42() {
            this.instance.SetFoobar( 42 ); 
        }

        public class GetAnswer : When_foobar_is_42
        {
            private Int32 result;

            public GetAnswer() {
                this.result = this.GetAnswer();
            }

            public void should_return_42() {
                Assert.AreEqual( 42, result );
            }
        }
    }
}

테스트 러너의 출력을 제공 할 것입니다.

MyClassSpecification+When_foobar_is_42+GetAnswer
    should_return_42

나는 당신이 당신의 질문에 묘사 한 두 가지 도로와 다른 몇 가지 도로를 따라갔습니다 ... 당신의 첫 번째 대안은 대부분의 사람들에게 매우 간단하고 이해하기 쉽습니다. 나는 개인적으로 BDD 스타일 (두 번째 예)을 더 좋아합니다 (두 번째 예)는 그러한 맥락에서 다른 맥락과 그룹 관찰을 분리하기 때문에 더 좋아합니다. 실제 단점만이 더 많은 코드를 생성한다는 것입니다. 따라서 시작하기 시작하면 깔끔한 테스트를 볼 때까지 약간 더 번거로운 느낌이 듭니다. 또한 상속을 사용하여 고정 장치 설정을 재사용하면 상속 체인을 출력하는 테스트 런너가 필요합니다. "an_empty_stack"클래스를 고려하면 재사용을 재사용하려면 다른 클래스를 수행하여 "when_five_is_pushed_on : an_empty_stack" "when_five_is_pushed_on"이 아니라 출력으로 원합니다. Testrunner 가이 지원을 지원하지 않으면 테스트에는 "when_five_is_pushed_onmpy_stack : an_empty_stack"과 같은 중복 정보가 포함됩니다.

테스트 사례 클래스를 호출하는 데 투표합니다. http://xunitpatterns.com/organization.html 그리고 http://xunitpatterns.com/organization.html#test%20naming%20conventions

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top