단위 테스트가 익숙하지 않은 코드를 이해하기 위해 문서 작성자 역할을 할 수 있다는 것을 여러 번 읽었습니다. 나는 단위 테스트와 TDD가 너무 자주 잘못 수행되었다는 것을 발견했다. 그리고 독서 단위 테스트는 테스트 자체의 코드를 읽는 것보다 더 빠르고 더 가치있는 것을 제공하지 않는다. 이론과 이상적인 세계를 무시하고 실세계에서 문서화 된 단위 테스트의 아이디어가 현실에서 얼마나 현실적인가?"단위 테스트는 문서 형식"입니까?
단위 테스트는 메서드가 수행하는 작업을 설명하는 것이 아니라 단위의 특정 워크 플로에서 얻어야하는 작업을 설명하기위한 것입니다. 단위가 여러 가지 방법에 걸쳐있을 수 있기 때문에 단위을 사용했지만 방법은이 아니므로 유의하십시오.
a recent post of mine on CodeReview에서 메소드의 이름을 [UnitOfWorkName]_[ScenarioUnderTest]_[ExpectedBehaviour]과 같은 형식으로 사용하면 테스트중인 워크 플로의 작동 방식을 한 눈에 알 수있는 정보를 읽을 수 있습니다. 나는 하나 개의 실행 경로 뒤에 의도는 일반 텍스트의 한 줄을 읽어 정확히 무엇인지 이제
createUser_WithNonExistingEmail_ShouldReturn_StandardCitiesAndCategories
:
가 진행 예 예를 들어,이 메소드 이름을 건설했다. 좋은 테스트 커버리지를 보유하고 있다면 장치가 무엇을하는지 쉽게 이해할 수있는 개요를 얻을 수 있습니다.모든 관련 단위 테스트를 거치고 이름을 해석하고 정확히 어떻게 서로 다른지를 알아내는 번거 로움일지도 모르겠다.
그러나 여전히 그 진술에는 하나의 큰 장점이 있습니다 : 버그 수정. 버그 수정은 특히 버그를 해결하는 단위 테스트와 함께해야합니다. 아직 다른 실행 경로가이 버그로 문서화되어 있습니다.이 버그는 나중에 유용한 문서를 제공 할 수 있습니다. 사람들이 관련된 모든 버그에 대해 메소드에 주석을 쓰고 싶지는 않습니다.
이 모든 존재는 말했다 :이 문서를 대체, 그것은 단순히 또한의 하지입니다. -이 IDE의에 의해 포착하고 XML 스타일 (C 번호) 또는 JavaDoc의 예를 들면, mousehover에 대한 정보를 제공됩니다> (자바
은 문서의 몇 가지 유형이 있습니다)
는 그래서 그래, 결국 그냥 양식을 실수하지 않는, 참으로 문서의 형태입니다.
통찰력을 가져 주셔서 감사합니다. 나는 위의 접근법에 대해 테스트 메소드 이름 지정에 동의한다. (나는 다른 구문으로 익숙하지만 아이디어는 같다.)그러나 저는이 접근법이 실제로 현실적인지 얼마나 궁금합니다. 즉, 수백 명의 커미터가있는 프로젝트를 포함하여 사람들이 실제로이를 100 % 준수하는 것입니다. 나는 이와 같은 접근법을 고수하려고 노력하지만 항상 효과가 없습니다. – jordan
이것은 흥미로운 질문입니다. 아마도 "단위 테스트를 읽을 수있는 문서 형식으로 만드는 방법"이라고 다시 말할 수있을 것입니다. 더 적은 의견 일 것입니다. – guillaume31