단위 테스트를 사용하면 도메인이 매우 작으므로 쉽습니다. 나는 Osherove의 methodName_conditions_result()계획을 사용했으며 매우 분명했습니다.
그러나 통합 테스트를 통해 매우 긴 이름을 갖게 될 것으로 생각되며 대신 무엇을 배치 methodName해야합니까? 통합 테스트 클래스의 이름을 어떻게 지정합니까?
통합 테스트 이름의 실제 예는 매우 환영합니다. 답변이 이러한 테스트를 더 잘 이해하는 데 도움이되기를 바랍니다.
답변:
단위 및 통합 테스트와는 조금 다른 접근 방식을 취합니다. 가능한 한 기능을 기반으로 이름을 지정하려고합니다. 그런 다음 모든 테스트를 통과하면 작동하고 작동하지 않는 모든 기능의 목록을 볼 수 있습니다.
테스트 이름을 이런 식으로 지정하는 것이 항상 실용적이지는 않지만 특히 수백 개의 단위 및 통합 테스트를 읽은 후에는 매우 유용 할 수 있습니다. 이러한 메소드를 보유한 모든 클래스 이름은 테스트중인 기능을 나타냅니다. 조직에 도움이 될 것입니다.
또한 bugfix1002버그가 수정되었음을 증명하기 위해 고유 한 접두어로 버그 수정에 대한 단위 테스트의 이름을 지정하는 것이 좋습니다 .
이것은 실제로 단위 테스트를 돕기 위해 작성되었지만 통합 테스트에 동일한 규칙이 적용되는 것을 알 수 있습니다.
일곱 단계를 확인하십시오 !
내가 선호하는 것은 당신이 부르는 것이 무엇이든, 실제로 테스트 스위트 이름 (우리 카드의 고정 장치 이름), 확인하는 효과 및 눈에 띄고 오류의 원인을 분명히 해야하는 주장 메시지입니다. Asherove의 이름을 사용하여 가장 쉬운 방법을 찾으면 진심으로 승인합니다. 그러나 요령은 조건, 결과 및 예외가 의미가있는 모든 것으로 "방법"부분을 채우는 것입니다.
"AccountDoesntExist"라는 테스트와 함께 "MakingADeposit"이라는 제품군과 "Expected NonesuchAccount exception-none received"라는 오류가 표시됩니다.
또는 "::"로 테스트 스위트 이름을 분리하는 것이 마음에 들지 않으면 "AccountHandling :: MakingADeposit_AccountDoesntExist_ThrowsAnException"으로도 괜찮습니다.
또한 좋은 이름이없는 경우 계속 진행하고 더 좋은 이름을 제시 할 것을 제안합니다 (코드를 CI에 제출하기 전).
통합 테스트는 각 테스트가 요구 사항의 한 측면을 테스트하지만 시스템 전체를 테스트한다는 점에서 단위 테스트와 유사한 규칙을 따라야합니다. 클래스는 "TpcInputValidation"과 같이 테스트중인 전체 항목의 이름을 지정해야하며 메소드의 이름은 지나치게 간결하지 않고 테스트가 수행하려는 작업을 표현 적으로 반영해야합니다 (예 : "shouldRaiseValidationErrorWithBadDates ()").
이 방법은 기능에 대한 하나의 개념을 테스트해야하며 많은 수의 주장이 달리 나타낼 수 있습니다. (참조 : "Clean Code : Agile Software Craftmanship 핸드북", 132 쪽, Robert Martin).
문제는 적절한 기능 이름이 메소드 이름에 비해 너무 길다는 것입니다. 나는 이름이 같은 테스트 메소드를 작성하는 것이 어색하고 registerAndValidateUnderageUniversityDriverWithCoverageSetA_test()긴 메소드 이름에 대한 컴파일러 규칙을 깨뜨릴 수 있음을 알고 있습니다 (PL / SQL은 최대 30 자만 허용합니다-Java 및 C #이 짧은 이름 제한을 부과하는지는 알지 못하지만 그렇지 않으면 특정 지점을 지나치지 않고 실제로 실제로 긴 메소드 이름이 생성 된 다른 코드에서 읽거나 관리하는 생성 된 코드에만 유용 할 수 있습니다). 당신은 그것을 단축하려고 시도 할 수 regValUnderageUnivDrvrWCovrgA_test()있지만 그것은 정말 읽기 끔찍합니다. 내가 좋아하지 않았지만 당시 최고의 선택이었습니다.underageUnivDrvr_test_01()그런 다음 메소드 이름을 테스트중인 기능에 대한 더 긴 설명으로 맵핑하는 스프레드 시트가있었습니다. 못 생겼지 만 효과가있었습니다. 소스 파일의 함수 문서에 테스트 설명을 문서화 할 수도 있습니다. 스프레드 시트와 코드간에 앞뒤로 맵핑하는 대신 코드에서 직접 테스트 문서를 생성 할 수 있기 때문에 유용 할 수 있습니다.