인프런 커뮤니티 질문&답변

안녕하세요, awldnjs2 님!

물론 문서 생성 테스트와 일반 테스트를 하나로 만들어서 관리해도 무방합니다만, 그렇게 관리한 이유는 다음과 같습니다.

• 보통 문서를 위한 테스트는 해피 케이스만 검증해서 문서를 생성하기 때문에, 예외 케이스에 대한 테스트가 어딘가에서 필요합니다.

  • 물론 필요한 경우 문서에 예외 케이스를 추가할 수도 있습니다. (다만 모든 예외 테스트 케이스를 문서로 만든다? 에 대해서는 물음표이긴 합니다.)

• 테스트는 필요하나, 문서로 만들고 싶지 않은 API가 있을 수도 있습니다.

  • ex) 외부에 공유하는 것이 아니라 팀 내부에서만 사용되는 API

위와 같은 이유로 저는 문서를 위한 테스트를 별도로 작성하는 것을 선호합니다.

도움이 되셨으면 좋겠네요.
감사합니다. 🙂

안녕하세요, 인프런 AI 인턴입니다.

@WebMvcTest 애노테이션을 사용하는 경우와 DocsTest를 분리하여 작성하는 이유에 대해서 궁금하신 것 같습니다.

먼저, @WebMvcTest는 Spring MVC 컨트롤러에 집중할 수 있도록 스프링 테스트 컨텍스트를 구성합니다. 이 애노테이션은 Spring MVC 인프라를 자동 구성하고 @Controller, @ControllerAdvice 등과 같은 MVC에 관련된 빈들만 스캔합니다. 따라서, 순수하게 컨트롤러의 동작을 검증하고자 할 때 매우 유용합니다.

반면, DocsTest와 같은 테스트는 Spring REST Docs를 활용하여 API 문서를 자동으로 생성하는 것을 목적으로 합니다. 이 과정에서 @WebMvcTest를 사용한 테스트 코드와 유사한 형태가 될 수 있지만, 목적 자체가 API 문서를 생성하는 데에 있으므로 문서화 작업에 필요한 추가적인 설정이나 코드가 포함될 수 있습니다.

실무 환경에서는 이 두 가지 접근 방식을 목적에 따라 분리하여 사용하곤 합니다. 컨트롤러의 동작 자체만을 검증하고자 할 때는 @WebMvcTest를 사용하고, API 문서를 생성하고자 할 때는 DocsTest와 같이 REST Docs를 사용하는 테스트를 별도로 작성합니다. 두 테스트가 동일하게 보일 수 있지만, 각각의 목적에 맞게 세분화하여 관리함으로써 테스트의 명확성을 유지하고, 유지보수성을 높일 수 있습니다.

물론, 프로젝트의 규모나 팀의 작업 방식에 따라 이 두 가지를 통합하여 관리하는 경우도 있을 수 있습니다. 그러나 일반적으로 명확한 목적의 분리를 통해 보다 관리하기 쉽고, 목적에 부합하는 테스트를 진행하는 것이 좋습니다.

awldnjs2님의 학습에 도움이 되었길 바라며, 추가적인 질문이 있으시다면 언제든지 문의해 주세요. 감사합니다!