크롬에서 API 응답 바꾸기, 서버 수정 없이 UI 시험하는 법

서버가 내려준 JSON을 내 브라우저에서 바꾼다

API가 늘 같은 데이터를 반환해 빈 목록이나 긴 상품명을 시험하기 어렵다면, 크롬 DevTools의 Override content로 응답을 바꿀 수 있다. XHR·fetch 응답 교체는 이미 제공되던 기능이다. 백엔드에 테스트용 분기를 추가하기 전에 프런트엔드 화면을 확인하는 데 쓸 수 있다.

1. DevTools의 Network를 연 뒤 해당 화면을 불러온다.
2. Fetch/XHR에서 대상 요청을 찾아 우클릭하고 Override content를 선택한다.
3. 처음 설정한다면 저장 폴더를 고르고 Allow로 접근을 허용한다.
4. Sources에 열린 응답 데이터를 수정하고 저장한다.
5. 페이지를 새로고침해 같은 데이터를 다시 요청한다.

이때 저장한 것은 서버의 데이터가 아니라 브라우저가 대신 읽을 파일이다. 응답을 바꾸는 시험과 실제 API에 데이터를 저장하는 작업은 구분해야 한다.

빈 배열·긴 문자열처럼 한 조건씩 바꾼다

첫 시험은 응답 전체를 새로 만드는 것보다 화면이 읽는 값 하나를 바꾸는 방식이 단순하다. 예를 들어 상품 목록 응답이 다음 구조라면 빈 결과를 표현하는 테스트 데이터를 만들 수 있다.

{
  "items": [],
  "total": 0
}

이 예시는 items와 total을 사용하는 API를 가정한다. 실제 응답이 다른 키나 중첩 구조를 쓰면 그 구조를 유지해야 한다. 배열을 문자열로 바꾸면 ‘목록이 비었을 때’가 아니라 ‘응답 형식이 잘못됐을 때’를 시험하게 된다.

다음에는 항목 하나를 남겨 상품명을 길게 바꾸거나, 숫자 필드를 0으로 바꿔 표시 상태를 살필 수 있다. 각각 빈 상태 안내, 줄바꿈, 0과 누락값의 구분을 확인하는 시나리오다. 한 조건씩 바꾸면 어떤 입력 때문에 화면이 달라졌는지 파악하기 쉽다.

화면보다 먼저 Response에서 적용 여부를 확인한다

Network의 응답 확인 기능으로 새 요청의 Response를 열면 페이지가 받은 내용을 볼 수 있다. 필터에 has-overrides:content를 입력하면 본문을 교체한 요청만 좁힐 수 있다. 응답을 바꿨는데 화면이 그대로라면 이 단계부터 확인한다.

Response가 원래 값이라면 방금 수정한 파일을 저장했는지, 같은 요청을 다시 발생시켰는지 살핀다. 바뀐 값이 보인다면 UI가 그 필드를 실제로 읽는지 확인할 차례다. 같은 화면에 요청이 여러 개라면 어느 응답이 해당 부분을 채우는지도 구분해야 한다.

Local Overrides 문서는 응답 본문 교체 시 Response 탭 옆의 보라색 표시도 안내한다. 한편 소스 맵에 연결된 파일은 직접 오버라이드할 수 없으며 원본 소스로 이동하는 안내가 나올 수 있다. 프로젝트의 원본 CSS·JavaScript를 계속 수정하려는 작업에는 Workspaces가 맞는다.

시험 데이터는 끄고, 실제 응답을 다시 받는다

시험을 마쳤다면 Sources → Overrides → Enable Local Overrides를 해제하고 페이지를 새로고침한다. 삭제와 비활성화는 다르다. 파일을 남겨두면 다음에 같은 시나리오를 다시 쓸 수 있다.

Local Overrides를 켜면 캐시가 자동으로 비활성화된다. 따라서 이 상태에서 본 로딩 시간을 평소 캐시를 쓰는 방문의 결과와 그대로 비교해서는 안 된다. 실제 응답을 볼 때는 Network의 캐시 설정도 함께 확인한다.

10월 DevTools 업데이트 안내에는 HTTP(S)가 아닌 data:·blob: 같은 URL에 오버라이드를 만드는 동작을 막는 변경도 포함됐다. API 응답 시험은 Network에 잡힌 실제 HTTP(S) 요청에서 시작한다. 마지막에는 오버라이드를 끈 상태의 Response와 화면을 다시 확인해야 테스트 데이터와 서버 결과를 혼동하지 않는다.