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

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

YunJeong님, 질문하신 부분에 대해 답변 드립니다.

테스트 중에 특정 객체를 대체하기 위해 FakerMailSender와 같은 가짜 객체(faker 또는 mock 객체)를 사용하는 경우, 실제 구현의 변경에 따라 가짜 객체도 계속 업데이트 해야 하는 문제가 있습니다. 이러한 문제를 최소화하기 위한 방법으로는 몇 가지 접근 방법이 있습니다.

1. 인터페이스를 사용한 결합도 낮추기: 실제 MailSender와 FakerMailSender가 동일한 인터페이스를 구현하도록 설계함으로써, 객체의 구조가 변경되었을 때 인터페이스를 구현하는 방식으로만 변경을 지원하게 함으로써, 결합도를 낮추고 변경 관리를 쉽게 할 수 있습니다.

2. 테스트 코드의 유지보수성 확보: 테스트 코드는 가능한 한 간단하고 명확하게 작성하여, 변경이 발생했을 때 쉽게 수정할 수 있도록 합니다. 테스트가 특정 구현에 의존하지 않는 방식을 선택하는 것이 중요합니다.

3. @MockBean을 이용한 스프링 부트 테스트 지원 활용: 스프링 부트는 테스트에 유용한 몇 가지 애너테이션을 제공하는데, @MockBean을 사용하여 어플리케이션 컨텍스트에서 요구하는 빈을 목킹할 수 있습니다. 이 방법을 사용하면 실제 구현이 변경되더라도 테스트 코드에는 영향을 미치지 않으며, 손쉽게 의존성을 관리할 수 있습니다.

4. 통합 테스트와 단위 테스트 분리: 가능한 한 통합 테스트와 단위 테스트를 명확히 분리하고, 단위 테스트에서는 실제 인프라스트럭처와의 상호작용을 최소화합니다. 이렇게 함으로써, 대부분의 로직을 단위 테스트로 검증하고, 실제 객체와의 상호작용은 통합 테스트에서만 수행하여 테스트의 복잡성을 관리할 수 있습니다.

어떤 방법을 선택하든 중요한 것은, 테스트가 어플리케이션 코드의 유지보수성을 저해하지 않고, 오히려 개발 프로세스를 지원하도록 하는 것입니다.

참고하셨으면 좋겠습니다.