작성
·
210
·
수정됨
0
학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요!
먼저 유사한 질문이 있었는지 검색해 보세요.
서로 예의를 지키며 존중하는 문화를 만들어가요.
안녕하세요! 이번 강의 편에서 외부 API mocking에 대해서 다뤄주셔서 감사합니다!
궁금한점이 현재 메일을 보내는 sendEmail의 경우 반환타입이 boolean이라 쉽게 테스트가 가능한것 같은데,
만일 RestTemplate/RestClient 와 같이 외부 API 연동한걸 mockito사용해서 가짜 객체로 테스트한다고 했을때, 실제 응답으로 받은 Json의 구조가 복잡할 경우에 어떻게 할지 궁금합니다.
thenReturn() 메서드에 해당 응답의 Json구조를 반영한 DTO를 넣어주면 될까 싶었는데, 결국에는 외부 API 응답 구조를 알고 있어야 되는 거라 의존적이라고 생각이 들거든요! 만약 외부 API 응답의 Json 구조가 달라지면 테스트가 깨지게 되는건데, 외부 응답 구조를 몰라야 mocking의 의미가 있는게 아닌지 헷갈립니다.
답변 3
1
안녕하세요, 세진:) 님!
일단은 외부 API의 응답 구조를 알아야하는건 필요한 일인데요.
프로덕션 코드에서 외부 API로 받아온 값을 알아야 그 다음 로직을 전개할 것이기 때문이죠.
결국은, 프로덕션 코드에서 알고 있어야 하는 응답 구조라면, 테스트 코드에서도 알고 있는게 자연스럽습니다.
보통은, (외부 API를 제공하는 입장에서) API의 응답 구조를 변경하는 일은 신중하게 생각해야 하는 일인데요.
말씀하신 것처럼 아무런 공지 없이 API의 스펙을 변경해버리면 해당 API를 사용하고 있는 모든 시스템에서 장애가 날 확률이 높습니다.
항목을 추가
하는 것은 괜찮으나(받아보는 쪽에서 사용하지 않고 있는 값일테니까요), 변경
이나 삭제
에 대해서는 민감하게 고민해야 합니다.
그래서 API 응답 항목의 변경/삭제가 필요하면 API의 버전을 올리는 형태로 진행합니다.
사용하는 쪽에서는 버전이 올라간 API가 필요한 경우에, 버전을 올려서 다시 그에 맞게 DTO를 수정하면 되겠죠. ㅎㅎ
도움이 되셨기를 바랍니다.
감사합니다. 🙂
0
0
안녕하세요, 인프런 AI 인턴입니다.
복잡한 JSON 구조를 가진 외부 API의 응답을 mocking할 때 가장 중요한 것은 테스트의 목적을 명확히 하는 것입니다. 마찬가지로, 실제 외부 API 응답의 전체 구조를 모방하기보다는 테스트하고자 하는 기능에 중접적인 데이터만을 포함하는 DTO를 생성하여 사용하는 방법이 현명합니다. 외부 API 응답의 구조가 변경되었을 때 테스트가 깨지는 문제는 불가피하게 응답 구조에 어느 정도 의존하게 되므로, 외부 API의 변경 사항을 주기적으로 검토하고 테스트 코드를 업데이트하는 유지보수 작업이 필요합니다.
Mockito에서 thenReturn()
메서드를 사용하여 미리 정의된 DTO를 반환하도록 설정하는 것은 일반적인 방법입니다. 이 때, 필요한 것은 테스트하려는 기능에 실제로 영향을 미치는 데이터 필드만을 포함하도록 DTO를 단순화하는 것입니다. 이렇게 하면, 외부 API 응답의 불필요한 부분에 대한 의존도를 낮출 수 있으며, API 응답 구조가 약간 변경되더라도 테스트 코드를 보다 유연하게 유지할 수 있습니다.
외부 API 응답의 구조가 변경되었을 때 테스트가 깨지는 것을 완전히 피할 수는 없지만, 접근 방식을 통해 이러한 변경의 영향을 최소화시킬 수 있습니다. 이는 외부 응답 구조를 최대한 모르고자 하는 mocking의 의미와는 다소 차이가 있지만, 실제 서비스의 안정성을 보장하기 위한 실용적인 방안으로 볼 수 있습니다.
또한, 실제 외부 API와의 통합 테스트를 위해 별도의 통합 테스트 케이스를 구성하는 것도 좋은 방법입니다. 이런 통합 테스트는 외부 서비스와의 인터페이스가 정상적으로 작동하는지를 확인하는 데 중점을 두며, 애플리케이션의 주기적인 유지보수 과정에서도 유용하게 활용될 수 있습니다.
정리하자면, 복잡한 외부 API 응답을 mocking할 때는 테스트하고자 하는 기능에 집중하고, 필요한 데이터만을 포함한 DTO를 사용하는 것이 핵심입니다. 외부 API의 변경에 유연하게 대응하려면, 테스트 코드의 유지보수성을 고려하는 것이 중요합니다.