인프런 커뮤니티 질문&답변
작성한 질문수
WebApiExRateProvider 템플릿 콜백 패턴을 적용하면서 테스트 코드를 만들어보았습니다.
작성
·
28
·
수정됨
0
안녕하세요.
우선 한푼도 아깝지 않은 명강의를 만들어주심에 진심으로 감사드립니다.
WebApiExRateProvider를 템플릿 콜백 패턴을 적용한 구조로 변경하면서, 토비님께서는 실제 API를 호출하고 콘솔에 찍힌 결과를 보며 진행한 테스트 방식에 의문이 들어 한번 테스트 코드를 만들어보았는데요. 피드백을 받아보고 싶습니다.
코드는 GitHub Repository에 Commit 내역에서 확인하실 수 있습니다. (Commit 내역 링크)
의도에 대해 간단히 설명드리면 반드시 지정된 URL로 API 호출을 보내야 한다는 동작과 특정 스펙의 JSON을 파싱해서 환율 정보를 반환하는 동작을 테스트했습니다.
이때 ApiExecutor 의 경우 단순히 API를 호출하고 그 응답을 반환하는 역할이므로 테스트 할 가치가 없다고 판단하여 배제했습니다.
주로 궁금한 것은 다음과 같습니다.
테스트하려는 기능에 대해 부족하거나 과함은 없는지?
Mock을 활용한 테스트 방식에 대해서는 아쉬움이 없는지?
아무래도 Mock을 활용한 테스트에는 찝찝함이 남아있는데, 어떻게 해소할 수 있을지?
토비님이라면 어떤 식으로 테스트를 진행하셨을 지?
다시 한번 좋은 강의 제공해주셔서 진심으로 감사합니다.
답변 2
0
API가 사용하는 URL을 검증하는 테스트로군요. 좋은데요.
URL은 외부 설정에 의해서, 또는 하드코딩된 코드에 의해서 결정되는데 이걸 검증한다면, 아무래도 코드에 고정된 URL인 경우에 유효할 것입니다. URL을 다른 걸 사용하지 않도록 강제하는 경우겠죠.
반면에 빈 설정이나 프로퍼티 등을 통해서 URL을 넣는 경우라면 프로퍼티 값과 실제 사용되는 URL이 일치하는지를 테스트 하면 되겠네요.
어쨌든 Mock을 이용해서 사용 URL을 캡처하는 고급 기법을 잘 사용하셨습니다.
저는 실제로 이렇게까지는 테스트를 하지 않습니다. 아마 사용하는 API 서비스가 하나 새로 선택된다면 수동적으로 확인 가능한 테스트를 해서 API 사용 코드가 잘 동작하는지 확인해보고, 이후에는 그걸 믿고 사용할 겁니다.
외부 서비스를 이용하는 코드에 대해서 테스트하는 게 사실 쉽지는 않거든요. 환율이 어떻게 와야 성공인지 결정할 수 없기 때문이기도 하고, 테스트 하는 동안에 외부 서비스가 다운 되거나 네트워크 문제가 생기면 테스트가 실패하기 때문이죠.
그래서 API 호출하는 인터페이스까지 잘 넘어가지는지 정도만 고정된 테스트로 만드는 경우가 많습니다. 물론 아주 중요한 API라면 mock server를 이용한 테스트를 만들기도 합니다.
0
안녕하세요, 인프런 AI 인턴입니다.
생마차라거님께서 작성하신 WebApiExRateProvider의 테스트 코드에 대한 질문을 주셨네요.
테스트하려는 기능에 대해 부족하거나 과함은 없는지?
- 지정된 URL로 반드시 API 호출해야 하는 부분과 특정 스펙의 JSON 파싱 테스트는 WebApiExRateProvider의 핵심 기능을 검증하는 데 매우 중요합니다. 따라서 변경된 구조에 맞춰 주요 기능을 충실히 테스트하고 있다면, 부족하거나 지나친 부분 없이 잘 작성된 것으로 보입니다.
- 지정된 URL로 반드시 API 호출해야 하는 부분과 특정 스펙의 JSON 파싱 테스트는 WebApiExRateProvider의 핵심 기능을 검증하는 데 매우 중요합니다. 따라서 변경된 구조에 맞춰 주요 기능을 충실히 테스트하고 있다면, 부족하거나 지나친 부분 없이 잘 작성된 것으로 보입니다.
Mock을 활용한 테스트 방식에 대해서는 아쉬움이 없는지?
- Mock을 활용하여 외부 의존성을 격리하는 방식은 일반적으로 좋은 테스트 관행입니다. 중요한 것은 Mock이 실제 응용 프로그램에 얼마나 밀접하고 올바르게 설정되는지입니다. 그러나 Mock의 과도한 사용은 테스트의 신뢰성을 해칠 수 있기에 적절한 범위 내에서 사용하는 것이 중요합니다.
- Mock을 활용하여 외부 의존성을 격리하는 방식은 일반적으로 좋은 테스트 관행입니다. 중요한 것은 Mock이 실제 응용 프로그램에 얼마나 밀접하고 올바르게 설정되는지입니다. 그러나 Mock의 과도한 사용은 테스트의 신뢰성을 해칠 수 있기에 적절한 범위 내에서 사용하는 것이 중요합니다.
아무래도 Mock을 활용한 테스트에는 찝찝함이 남아있는데, 어떻게 해소할 수 있을지?
- 실제 환경과의 통합 테스트를 별도로 구현하여 Mock 테스트가 가지는 근본적인 불확실성을 보완할 수 있습니다. 예를 들어, 테스트 격리가 가능하도록 외부 API를 속한 작은 샌드박스 환경에서의 통합 테스트를 진행해보는 것도 방법입니다.
- 실제 환경과의 통합 테스트를 별도로 구현하여 Mock 테스트가 가지는 근본적인 불확실성을 보완할 수 있습니다. 예를 들어, 테스트 격리가 가능하도록 외부 API를 속한 작은 샌드박스 환경에서의 통합 테스트를 진행해보는 것도 방법입니다.
토비님이라면 어떤 식으로 테스트를 진행하셨을 지?
- 토비님 역시 주요 비즈니스 로직에 대해 Mock을 활용하여 단위 테스트를 진행하시고, 실제 작동 여부를 보장하기 위해 통합 테스트 환경을 추가로 구성하셨을 것입니다. 이는 웹 API와 같은 외부 시스템과의 상호 작용이 필요한 경우에 더욱 필요할 것입니다.
- 토비님 역시 주요 비즈니스 로직에 대해 Mock을 활용하여 단위 테스트를 진행하시고, 실제 작동 여부를 보장하기 위해 통합 테스트 환경을 추가로 구성하셨을 것입니다. 이는 웹 API와 같은 외부 시스템과의 상호 작용이 필요한 경우에 더욱 필요할 것입니다.
추가로, 아래 Spring Boot의 테스트 관련 문서를 통해 더 다양한 테스트 방법 및 전략을 이해해보시면 도움될 것 같습니다:
- Spring Boot Reference: Testing with Mock Environment
- Spring Boot Reference: Auto-configured Spring MVC Tests
감사합니다. 꼭 유익한 시간이 되시길 바랍니다.