개념
화면 없이 서버와 직접 대화한다
모듈 9(레슨 2)에서 배운 HTTP 요청·응답 구조를 떠올려보자. 사용자가 버튼을 클릭하면 브라우저가 서버에 요청을 보낸다 — API 테스트는 이 요청을 브라우저 화면을 거치지 않고 직접 서버에 보내서 응답을 검증하는 방식이다.
UI 테스트: 화면 클릭 → 브라우저가 요청 생성 → 서버 응답 → 화면에 반영 → 확인
API 테스트: 요청을 직접 생성 → 서버 응답 → 응답 자체를 확인자동화 피라미드에서 API 테스트의 위치
모듈 11(레슨 1)에서 배운 피라미드를 떠올리면, API 테스트는 보통 통합 테스트 계층에 해당한다 — 여러 컴포넌트(서버 로직, 데이터베이스)가 맞물려 동작하는지 확인하되, 화면 렌더링이라는 가장 불안정하고 느린 요소는 건너뛴다.
▲
/E2E\
/-----\
/ API \ ← API 테스트가 주로 여기
/---------\
/ 단위 테스트 \
/---------------\API 테스트가 UI 테스트보다 유리한 이유
1. 빠르다 — 화면 렌더링, 애니메이션, 리소스 로딩을 기다릴 필요가 없다. 요청을 보내고 응답만 받으면 끝이다.
2. 안정적이다 — 모듈 7(레슨 3)에서 배운 플래키 테스트의 흔한 원인(요소를 못 찾음, 타이밍 문제)이 UI 테스트에는 있지만 API 테스트에는 훨씬 적다.
3. 원인 파악이 쉽다 — 실패했을 때, "화면의 어느 요소가 문제였는지" 추적할 필요 없이 응답 자체(상태 코드, 응답 본문)를 보면 바로 원인을 알 수 있다.
4. 백엔드 로직을 UI 없이도 검증할 수 있다 — 프런트엔드 개발이 아직 안 끝났어도, API가 준비되면 바로 테스트를 시작할 수 있다.
API 테스트로는 확인할 수 없는 것
API 테스트는 서버 로직의 정확성을 확인하지만, 사용자가 실제로 보는 화면은 확인하지 못한다. "API 응답은 맞는데 화면에 잘못 표시된다"는 프런트엔드 버그는 API 테스트로 절대 못 잡는다 — 이건 모듈 10(레슨 6)의 컴포넌트 테스트나 E2E 테스트의 영역이다. API 테스트는 피라미드의 한 계층일 뿐, 전체를 대체하지 않는다.
API 테스트가 검증하는 것들
- 상태 코드 — 모듈 9(레슨 2)에서 배운 2xx/4xx/5xx가 예상대로 나오는가
- 응답 본문 구조와 값 — 필요한 필드가 있는가, 값이 정확한가
- 응답 시간 — 너무 느리지는 않은가(성능 관점, 모듈 16과 연결)
- 에러 처리 — 잘못된 요청에 적절한 에러 응답을 주는가
이 목록을 얼마나 덮었는지 재는 법 은 레슨 8 에서 다룬다. 테스트 개수가 아니라 엔드포인트·실패 경로·파라미터·시나리오라는 네 층으로 나눠 측정하고, 실사용 호출량과 대조해 어디부터 보강할지 정하는 방법이다.
실무에서 왜 필요한가
프런트엔드가 아직 완성되지 않았어도 백엔드 API가 준비되면 QA가 바로 테스트를 시작할 수 있다는 것은, 모듈 4(레슨 4)에서 배운 일정 산정에 큰 영향을 준다 — 병렬로 검증을 진행할 수 있어 전체 일정이 단축된다. 또한 API 테스트가 안정적으로 자리 잡으면, UI 자동화(모듈 13)는 정말 "화면 자체의 문제"만 잡는 데 집중할 수 있어 피라미드가 건강해진다.