카카오페이 v2 테스트 커버리지 80% 맞추기

카카오페이 v2를 개발할 때 내부 품질 게이트는 새로 작성하거나 변경한 코드에 대해 테스트 커버리지 80% 이상을 요구했습니다. 기능이 동작하는 것 외에 테스트와 정적 점검 기준도 통과해야 배포할 수 있었습니다.

개발 후반에 테스트를 보강하려니 외부 API 호출과 상태 처리, 저장 과정이 이어진 코드부터 다루기 어려웠습니다. 테스트를 추가하는 작업과 코드를 나누는 작업을 함께 진행했습니다.

테스트 리포트 설정 확인

먼저 테스트 결과가 품질 도구에 제대로 전달되는지 확인했습니다. 테스트가 실행됐더라도 도구가 리포트를 읽지 못하면 실제 결과가 반영되지 않습니다. 당시에도 테스트 리포트 경로를 수정하는 작업이 필요했습니다.

JUnit 테스트 결과와 코드 커버리지 리포트는 구분해서 봐야 합니다. 테스트 성공·실패를 보여주는 결과 파일과 어떤 코드가 실행됐는지 보여주는 커버리지 파일은 역할이 다릅니다. 품질 도구의 수치가 예상과 다를 때는 테스트가 실행됐는지와 각 리포트가 수집됐는지를 따로 확인해야 합니다.

외부 호출과 상태 처리 분리

결제 서비스의 정상 요청은 외부 API를 호출하고, 응답으로 상태를 판단한 다음, 결과를 저장하는 순서로 이어집니다. 이 과정이 한곳에 모여 있으면 상태 판단 하나를 테스트할 때도 HTTP 통신과 DB 저장을 함께 준비해야 합니다.

역할을 나눠 각 부분을 따로 테스트할 수 있도록 정리했습니다.

테스트마다 실제 외부 시스템에 연결하지 않아도 필요한 응답을 만들어 검증할 수 있게 하는 것이 목적이었습니다. 모킹해야 할 대상이 지나치게 많으면, 그 테스트가 확인하려는 역할보다 더 많은 일을 코드가 맡고 있는지도 다시 봤습니다.

실패하는 경우의 테스트

정상 결제만 테스트해서는 외부 연동의 오류 처리를 충분히 확인하기 어려웠습니다. API 타임아웃이나 오류 응답, 저장 실패, 잘못된 입력처럼 중간에 처리가 끝나는 경우도 확인해야 했습니다.

특히 결제 요청이 타임아웃됐다는 이유만으로 외부에서도 결제가 실패했다고 판단할 수는 없습니다. 통신 오류를 어떤 상태로 기록하고 이후 어떻게 확인할지는 결제 처리 규칙과 맞춰야 합니다. 그래서 예외가 발생하는지만 보는 테스트보다, 오류 이후 어떤 결과를 남기는지 확인하는 테스트가 필요했습니다.

커버리지와 테스트 범위

리포트 설정을 수정하고 코드를 나눠 테스트를 보강하면서 80% 이상이라는 기준을 맞췄습니다. 다만 커버리지는 코드가 실행됐는지를 나타낼 뿐, 그 테스트가 결제 결과를 올바르게 검증하는지까지 알려주지는 않습니다.

테스트를 작성하기 쉬워지면 정상 응답 외의 경우도 확인하기 수월했습니다. 이후에는 기능을 다 만든 다음 테스트할 방법을 찾기보다, 외부 통신과 상태 판단을 처음부터 따로 다룰 수 있는지 함께 생각하게 됐습니다.

다음 글에서는 테스트를 보강한 뒤에도 운영 중 발생했던 큰따옴표로 인한 결제 요청 파싱 오류를 다룹니다.