단위 테스트에 대한 인기있는 명명 규칙은 무엇입니까? [닫은]

일반

• 모든 테스트에 대해 동일한 표준을 따르십시오.
• 각 테스트 상태가 무엇인지 명확히하십시오.
• 예상되는 행동에 대해 구체적으로 설명하십시오.

예

1) MethodName_StateUnderTest_ExpectedBehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

출처 : 단위 테스트의 명명 표준

2) 밑줄로 각 단어 분리

Public void Sum_Negative_Number_As_1st_Param_Exception_Thrown() 

Public void Sum_Negative_Number_As_2nd_Param_Exception_Thrown () 

Public void Sum_Simple_Values_Calculated ()

다른

• Test를 사용하여 종료 메소드 이름
• 클래스 이름으로 메소드 이름 시작

나는이 한 사람에 대해 당신과 거의 비슷합니다. 사용한 명명 규칙은 다음과 같습니다.

• 각 테스트 상태가 무엇인지 분명히하십시오.
• 예상되는 행동에 대해 구체적입니다.

시험 명에서 더 필요한 것이 있습니까?

Ray의 답변과 달리 Test 접두사가 필요 하다고 생각하지 않습니다 . 테스트 코드입니다. 코드를 식별하기 위해이 작업을 수행해야하는 경우 더 큰 문제가있는 경우 테스트 코드를 프로덕션 코드와 섞어서는 안됩니다.

밑줄의 길이와 사용에 관해서는, 테스트 코드 는 누구를 걱정합니까? 읽을 수 있고 테스트가 수행중인 작업에 대해 분명한 한 귀하와 귀하의 팀만이이를 볼 수 있습니다. :)

즉, 나는 여전히 내 모험 을 테스트하고 블로깅하는 것에 매우 익숙합니다. :)

이것 또한 읽을 가치가 있습니다 : 구조화 단위 테스트

이 구조에는 테스트중인 클래스 당 테스트 클래스가 있습니다. 그렇게 드문 일이 아닙니다. 그러나 나에게 특이한 점은 테스트 할 각 방법마다 중첩 클래스가 있다는 것입니다.

예 :

using Xunit;

public class TitleizerFacts
{
    public class TheTitleizerMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void Name_AppendsTitle()
        {
            // Test code
        }
    }

    public class TheKnightifyMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void MaleNames_AppendsSir()
        {
            // Test code
        }

        [Fact]
        public void FemaleNames_AppendsDame()
        {
            // Test code
        }
    }
}

그리고 여기에 이유가 있습니다 :

우선 테스트를 체계적으로 정리할 수있는 좋은 방법입니다. 분석법에 대한 모든 테스트 (또는 사실)가 함께 그룹화됩니다. 예를 들어, CTRL + M, CTRL + O 단축키를 사용하여 분석법 본문을 축소하면 테스트를 쉽게 스캔하고 코드 사양처럼 읽을 수 있습니다.

나는 또한이 접근법을 좋아합니다 :

MethodName_StateUnderTest_ExpectedBehavior

아마도 다음과 같이 조정하십시오.

StateUnderTest_ExpectedBehavior

각 테스트는 이미 중첩 클래스에 있기 때문에

MethodName_DoesWhat_WhenTheseConditions예를 들어 다음 과 같은 규칙을 사용하는 경향이 있습니다 .

Sum_ThrowsException_WhenNegativeNumberAs1stParam

그러나 내가 많이 보는 것은 테스트 이름이 단위 테스트 구조를 따르도록 만드는 것입니다.

• 가지런 히하다
• 행위
• 주장

또한 다음의 BDD / Gherkin 구문을 따릅니다.

• 주어진
• 언제
• 그때

다음과 같은 방식으로 테스트 이름을 지정합니다. UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

예를 들어 :

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

그러나 테스트 할 메소드 이름을 먼저 입력하는 것이 좋습니다. 테스트는 알파벳순으로 정렬되거나 VisStudio의 멤버 드롭 다운 상자에 알파벳순으로 정렬되어 표시 될 수 있으며 1 개의 메소드에 대한 모든 테스트가 함께 그룹화되기 때문입니다.

어쨌든, 나는 모든 단어 와 달리 테스트 이름 의 주요 섹션 을 밑줄로 분리하는 것을 좋아합니다 . 왜냐하면 테스트 포인트를 더 쉽게 읽고 읽을 수 있다고 생각하기 때문입니다.

즉, 내가 좋아하는 : Sum_ThrowsException_WhenNegativeNumberAs1stParam보다 나은 Sum_Throws_Exception_When_Negative_Number_As_1st_Param.

밑줄이나 구분 기호없이 "PascalCasing"을 사용하는 다른 방법과 마찬가지로 테스트 방법의 이름을 지정합니다. 메소드에 대한 접미사 테스트 를 생략하고 값을 추가하지 않습니다. 메소드가 테스트 메소드라는 것은 TestMethod 속성으로 표시됩니다 .

[TestMethod]
public void CanCountAllItems() {
  // Test the total count of items in collection.
}

각 테스트 클래스는 다른 클래스 하나만 테스트해야하기 때문에 클래스 이름을 메소드 이름에서 제외합니다. 테스트 메소드를 포함하는 클래스 이름은 "Tests"라는 접미사가 붙은 테스트중인 클래스와 같은 이름을 갖습니다.

[TestClass]
public class SuperCollectionTests(){
    // Any test methods that test the class SuperCollection
}

예외 또는 불가능한 동작을 테스트하는 메소드의 경우 테스트 메소드 앞에 Cannot 단어를 붙 입니다.

[TestMethod]
[ExpectedException(typeOf(ArgumentException))]
public void CannotAddSameObjectAgain() {
  // Cannot add the same object again to the collection.
}

내 이름이 바뀌는 것은 Bryan Cook의 "TDD 팁 : 테스트 명명 규칙 및 지침" 기사를 기반으로합니다 . 이 기사가 매우 유용하다는 것을 알았습니다.

CamelCasing은 단어를 분리하고 밑줄은 명명 체계의 일부를 분리하기 때문에 첫 번째 이름 세트는 더 읽기 쉽습니다.

또한 함수 이름이나 묶는 네임 스페이스 또는 클래스에 "Test"를 포함시키는 경향이 있습니다.

단일 연습을 따르는 한 실제로 중요하지 않습니다. 일반적으로 메서드의 모든 변형을 다루는 메서드에 대한 단일 단위 테스트를 작성하고 (단순한 메서드가 있습니다), 메서드가 필요한 메서드에 대해 더 복잡한 테스트 집합을 작성합니다. 따라서 내 명명 구조는 일반적으로 테스트 (JUnit 3의 인수)입니다.

테스트 네임 스페이스, 클래스 및 메서드에 'T'접두사를 사용합니다.

깔끔하고 네임 스페이스를 복제하는 폴더를 만든 다음 테스트 폴더를 만들거나 테스트를 위해 별도의 프로젝트를 만들고 기본 테스트를 위해 프로덕션 구조를 복제하십시오.

AProj
   Objects
      AnObj
         AProp
   Misc
      Functions
         AFunc
   Tests
      TObjects
         TAnObj
            TAnObjsAreEqualUnderCondition
      TMisc
         TFunctions
            TFuncBehavesUnderCondition

나는 무언가가 테스트라는 것을 쉽게 알 수 있습니다. 원래 코드가 어떤 것인지 정확히 알고 있습니다 (해낼 수 없다면 어쨌든 테스트가 너무 복잡합니다).

인터페이스 명명 규칙처럼 보입니다 (즉, 'I'로 시작하는 것과 혼동하지 않으며 'T'와도 혼동하지 않습니다).

테스트 유무에 관계없이 컴파일하기 쉽습니다.

어쨌든 이론 상으로는 좋으며 소규모 프로젝트에는 잘 작동합니다.