도구 소개
픽스처 파일이나 요청 본문의 구문 오류는 이해하기 어려운 테스트 실패의 가장 흔한 원인 중 하나입니다. 이 검사기는 엄격한 표준에 따라 JSON을 검사하고 첫 번째 오류를 줄과 열과 함께 보고하며, 유효한 경우에는 문서 구조(객체, 배열, 키, 깊이) 요약을 보여 줍니다. 구문이 아니라 데이터의 형태를 검증하려면 JSON Schema 검증기를 사용하세요.
사용 방법
- 검사할 JSON을 붙여 넣으세요.
- 결과 배너를 확인하세요. 초록색은 유효함을, 빨간색은 오류 메시지와 위치를 뜻합니다.
- 표시된 위치를 수정하면 입력하는 동안 결과가 갱신됩니다.
유효한 JSON의 기준
이 검사기는 JSON.parse와 같은 규칙인 RFC 8259의 엄격한 문법을 적용합니다. 문서는 하나의 값, 즉 객체, 배열, 문자열, 숫자, true, false, null 중 하나입니다. 따라서 대부분의 API가 객체를 반환하더라도 단독 "hello"나 42도 유효한 JSON입니다.
중복 키는 흔한 함정입니다. 표준은 객체 이름이 고유해야 한다(SHOULD)고만 할 뿐 중복을 금지하지 않으며, JSON.parse는 마지막 값을 조용히 유지합니다. 구문 검사는 {"id": 1, "id": 2}를 잡아내지 못하므로 코드 리뷰나 린터로 중복을 확인하세요.
오류 메시지 읽는 법
브라우저마다 파싱 오류 문구가 다릅니다. Chrome은 “Unexpected token”이나 “Expected property name” 같은 메시지와 위치를, Firefox는 줄과 열을 알려 줍니다. 어느 경우든 표시된 위치는 파서가 포기한 지점이며, 보통 실제 실수 바로 뒤입니다. 바로 윗줄의 쉼표 누락, 닫히지 않은 따옴표, 불필요한 괄호를 확인하세요.
자동화 테스트에서 JSON 검증하기
- Playwright: 본문이 유효한 JSON이 아니면
await response.json()이 예외를 던지므로 해당 줄에서 테스트가 실패합니다. 서버가 JSON 텍스트를 HTML로 표시해 보낼 수도 있으니response.headers()['content-type']도 확인하세요. - REST Assured:
.contentType(ContentType.JSON)을 어설션한 다음, json-schema-validator 모듈의matchesJsonSchemaInClasspath("order-schema.json")으로 구조를 확인합니다. - Postman: 유효하지 않은 JSON이면
pm.response.json()이 예외를 던지고,pm.response.to.be.json은 콘텐츠 타입을 어설션합니다. - 형태와 타입(필수 필드, 형식, enum)을 확인하려면 JSON Schema 검증기로 넘어가세요. 구문 검증은 텍스트가 파싱된다는 사실만 보장합니다.
JSON 유효성 검사기 자주 묻는 질문
JSON 유효성 검사와 스키마 검증은 어떻게 다른가요?
구문 검증은 텍스트가 올바른 형식의 JSON인지 확인합니다. 스키마 검증은 올바른 형식의 JSON이 “id는 필수 정수”처럼 기대한 필드, 타입, 제약 조건을 갖췄는지 확인합니다.
오류 위치가 왜 실제 실수보다 뒤를 가리키나요?
파서는 더 이상 진행할 수 없는 지점을 보고합니다. 쉼표나 따옴표 누락은 대개 표시된 위치 바로 앞에 있습니다.