팀에게 API 테스트가 무엇을 의미하는지 물어보면 대부분은 똑같은 것을 설명할 것입니다. 요청을 보내고, 상태 코드(status code)를 확인하고, 아마도 응답에서 필드 한두 개를 확인하는 것 말이죠. 그것은 하나의 테스트 유형이며, 모두가 수행하는 방식입니다. 하지만 그것은 실제 운영 환경의 장애를 가장 적게 잡아내는 방식이기도 합니다. 왜냐하면 사용자에게 실제로 도달하는 장애는

잘못된 형식(malformed), 누락되거나, 예상치 못한 입력을 전송하고 시스템이 정의되지 않은 방식으로 작동하는 대신 예측 가능한 방식으로 실패하는지 확인하는 것입니다. 값이 기대되는 곳에 빈 문자열을 넣거나, ASCII를 가정했을 때 유니코드(unicode)를 넣거나, 양수만 테스트되었을 때 음수를 넣는 식입니다. 이 카테고리는 대부분의 팀이 투자를 가장 적게 하는 분야이기 때문에, 작성된 테스트당 실제 버그를 발견하는 비율이 해피 패스 (happy-path) 기능 테스트보다 일관되게 높습니다. 또 다른 해피 패스 단언(assertion)을 작성하는 것보다 흥미로운 엣지 케이스 (edge cases)를 생각하는 것이 더 어렵기 때문입니다.

부하 및 성능 테스트 (Load and Performance Testing): 문제가 터지기 전까지는 보이지 않는 것

단일 요청이 아닌, 실제와 유사한 동시 트래픽 (concurrent traffic) 상황에서도 엔드포인트가 잘 버티는지 확인하는 것입니다. 부하 상황에서 무너지는 완벽하게 정확한 엔드포인트는 기능적으로 고장 난 엔드포인트보다 작은 문제가 아닙니다. 단지 더 최악의 순간, 즉 대개 하루 중 가장 중요한 사용량이 몰리는 트래픽 급증 (traffic spike) 시점에 실패할 뿐입니다.

보안 테스트 (Security Testing): 틀렸을 때의 비용이 가장 높은 것

API가 오용될 수 있는지 확인하는 것입니다: 인증 우회 (authentication bypass), 인젝션 (injection), 한 사용자가 다른 사용자의 데이터를 볼 수 있게 하는 부적절한 권한 부여 (improper authorization) 등이 해당됩니다. 이 카테고리는 전문 지식이 필요하다는 점을 고려할 때 별도의 팀이 다른 주기(cadence)로 운영하는 별개의 전문 분야로 취급되는 경우가 많으며 이는 합리적이지만, 그렇다고 해서 핵심 API 테스트 스위트 (test suite)가 권한 부여를 완전히 무시해도 된다는 의미는 아닙니다. 사용자가 자신의 레코드를 가져올 수 있는지는 확인하지만 다른 사람의 레코드를 가져올 수 있는지 여부는 전혀 확인하지 않는 테스트는, 실제 세상에서 가장 흔한 API 취약점 중 하나를 놓치고 있는 것입니다.

단일 카테고리 내의 양이 아닌, 카테고리 전반에 걸친 커버리지 구축하기

500개의 기능 테스트 (functional tests)를 갖추고 계약 테스트 (contract tests)가 하나도 없는 테스트 스위트는, 커버리지 보고서상의 수치가 아무리 인상적으로 보이더라도 실질적인 공백이 존재하는 것입니다. 위에 언급된 카테고리들은 한 번 완료하고 끝내는 체크리스트가 아니라, 중요한 모든 엔드포인트 (endpoint)에 적용해야 하는 관점입니다. 특정 중요한 엔드포인트에 대해, 한 카테고리의 높은 테스트 수가 다른 카테고리의 커버리지를 의미한다고 가정하기보다는, 이 다섯 가지 카테고리 중 어떤 것이 커버되었고 어떤 것이 커버되지 않았는지 명시적으로 질문해 볼 가치가 있습니다.

실제 캡처된 트래픽으로부터 테스트를 생성하는 Keploy의 방식은 실제 요청(request)과 응답(response) 쌍을 기록하기 때문에 자연스럽게 강력한 기능 및 계약 커버리지 쪽으로 기울어지지만, 트래픽 기반 생성 방식이라 할지라도 실제 트래픽이 아직 실행하지 않았을 수 있는 부정적 케이스 (negative cases)와 엣지 케이스 (edge cases)를 추가하기 위해 의도적인 검토 과정을 거치는 것이 유익합니다.

핵심 요점

모든 것을 커버하는 단 하나의 API 테스트 유형은 존재하지 않으며, 기능 테스트 (functional testing)를 업무의 전부로 취급하는 것이 다른 부분에서는 성숙해 보이는 테스트 스위트에서 가장 흔히 발생하는 공백입니다. 이미 어느 정도 잘 커버된 카테고리에 기능 테스트 20개를 더 추가하는 것보다, 가장 중요한 엔드포인트들을 대상으로 각 카테고리를 의도적으로 훑어보는 것이 오후 시간을 더 가치 있게 사용하는 방법입니다.