API 페이로드 생성기

API 페이로드는 요청이나 응답의 본문에 담기는 데이터로, REST API에서는 보통 JSON입니다. 예를 들어 POST /users 요청은 {"name": "Asha", "email": "asha@example.com"}을 보낼 수 있습니다. 메서드, URL, 헤더는 요청을 설명하고 페이로드는 그 내용입니다. 테스트에서 요청 페이로드는 입력이고 응답 페이로드는 어설션 대상이므로, 둘 다 API 계약과 일치해야 합니다.

API 계약에서 시작하세요. JSON Schema나 실제 요청 바디를 이 생성기에 붙여 넣으면 유효한 페이로드와 함께 규칙마다 하나씩 네거티브 변형을 만듭니다. 필수 필드 누락, 잘못된 타입, 범위를 벗어난 값, 잘못된 enum 등이 포함됩니다. JSON으로 내보내 테스트에서 반복 실행하세요. 현실적인 값을 대량으로 원하면 테스트 데이터 생성기를, 바로 쓸 수 있는 예시는 샘플 JSON 페이로드를 참고하세요.

리소스를 생성하기 위해 API 계약이 요구하는 것만 정확히 넣습니다. 올바른 타입과 형식의 모든 필수 필드, 그리고 시나리오에 관련된 선택 필드입니다. API가 기대하지 않는 한 id나 createdAt 같은 서버 생성 필드는 넣지 않아야 합니다. Content-Type: application/json 헤더와 함께 보내세요. 생성에 성공하면 보통 새 리소스나 Location 헤더와 함께 201 Created를 반환하고, 잘못된 페이로드는 명확한 오류와 함께 400 또는 422를 반환해야 합니다.

유효한 페이로드 하나를 기준으로 테스트마다 정확히 한 가지만 깨뜨리세요. 그래야 실패가 하나의 규칙을 가리킵니다. 대표적인 변형은 필수 필드를 하나씩 제거, 잘못된 타입이나 null 전송, 길이나 숫자 제한을 1만큼 초과, 잘못된 enum 값이나 형식이 깨진 이메일, 알 수 없는 속성 추가, 빈 객체 전송입니다. 각각 유용한 오류와 함께 4xx 상태로 거부되어야 하며, 절대 500이 나와서는 안 됩니다. 이 생성기는 스키마에서 이런 변형을 자동으로 도출합니다.

대부분의 REST API는 JSON 객체를 사용하며, address를 가진 사용자처럼 중첩 객체가 흔합니다. 그 밖에 일괄 처리용 객체 배열, 결과를 data와 meta 필드로 감싸는 엔벌로프, query와 variables를 담은 GraphQL 요청, 그리고 type, title, status, detail을 갖는 오류용 RFC 9457 problem details가 자주 쓰입니다. 현실적인 요청·응답 바디는 샘플 JSON 페이로드 라이브러리에서 살펴보세요.

네. 랜덤 데이터는 직접 고른 값으로는 놓치는 버그를 찾아내지만, 재현 가능해야 합니다. 테스트 데이터 생성기는 Faker로 현실적인 이름, 이메일, 주소, UUID, 숫자, 날짜를 만들며, 시드를 고정하면 매번 같은 데이터가 나오므로 실패한 테스트를 다시 재현할 수 있습니다. JavaScript와 Python의 Faker 라이브러리, Java의 Datafaker도 테스트 코드 안에서 같은 일을 합니다. 엣지 케이스 문자열은 테스트 문자열 생성기를 사용하세요.

보통 400 Bad Request 또는 422 Unprocessable Content이며, 오류 바디에 해당 필드명이 있어야 합니다. API 문서에 무엇이 정의되어 있든 엔드포인트 전반에서 일관되어야 하고, 이 변형들 중 어느 것도 500을 반환해서는 안 됩니다.

배열을 불러와 반복하세요. Playwright에서는 for (const { name, payload } of variants) test(name, ...), JUnit 5에서는 JSON 소스와 함께 @MethodSource 또는 @ParameterizedTest를 사용하고, Postman에서는 컬렉션 러너의 데이터 파일로 사용합니다.

스키마가 해당 필드에 null을 허용하면(type: ["string", "null"] 또는 enum에 null 포함) null 전송은 유효하므로 네거티브 케이스가 아닙니다.