SimpleWebUtils
ENKO

문서 작업 가이드

운영 데이터를 복사하지 않고 테스트 픽스처 만들기

픽스처 스키마를 정의하고 범위 숫자와 라벨형 문자열을 생성한 뒤 명시적 경계 오류를 추가하고, 정확한 JSON·CSV를 검증해 재현 가능한 테스트 데이터로 고정하는 실전 흐름입니다.

작성 및 검수 게시일: 검토일:

이 작업 흐름을 검증한 방법

랜덤 테스트 데이터 워크벤치 검토에서는 “공유 가능한 주문 가져오기 픽스처 만들기”에 표시된 원본을 보존했습니다. “운영 값을 변형하지 말고 독립적으로 대체하기”, “정확한 대상 형식으로 내보내고 검증하기” 단계를 완료한 뒤 가능한 값은 그대로 대조했습니다. 연결된 실패 증거는 “운영 내보내기를 그 자리에서 익명화하기”, “랜덤 정상값을 전체 커버리지로 간주하기” 항목별로 확인했습니다.

fixture에는 schema를 통과하는 합성 주문 10개와 수량·가격·고유성·UUID 누락·길이·CSV 인용 실패를 각각 확인할 경계 행이 들어갔고 운영 레코드는 재사용하지 않았습니다.

랜덤 테스트 데이터 워크벤치 | 숫자·문자열 생성 열기

문제 상황

운영 레코드를 테스트, 지원 티켓, 데모, 스크린샷에 복사하면 개인정보와 비밀값이 노출될 수 있습니다. 모든 필드를 짧은 임시값으로 바꾸면 안전하지만 실제 길이, 소수 간격, 고유성 제약, 유니코드, CSV 인용, JSON 숫자 타입에서 생기는 오류를 숨길 수 있습니다. 매번 랜덤 픽스처를 만드는 방식도 결과가 계속 바뀌고 정확한 경계를 거의 만나지 못합니다. 유용한 픽스처는 문서화된 스키마를 보존하고 운영 값을 포함하지 않으며, 대표 정상값과 의도적인 오류값을 분리하고, 정확한 결과를 비교하는 테스트에서는 안정적으로 유지돼야 합니다.

이럴 때 사용하세요

  • 고객, 테넌트, 주문, 계정 데이터 없이 공유 가능한 JSON 또는 CSV 버그 재현이 필요할 때
  • 가져오기 파이프라인에 현실적인 정상 행과 빈 값, 중복, 잘못된 형식, 최솟값, 최댓값 사례가 모두 필요할 때
  • 실제 계정이나 자격 증명으로 오해되지 않는 읽기 쉬운 데모·스크린샷 라벨이 필요할 때
  • 테스트가 실행 중 매번 새 랜덤 데이터를 만들고 정확한 비교가 간헐적으로 실패할 때

단계

  1. 1단계

    생성 전에 대상 스키마부터 기록하기

    각 필드 이름, 데이터 타입, null 허용 여부, 최소·최대, 소수 스케일, 길이, 허용 문자 집합, 고유성 범위, 의미 형식을 적습니다. UUID, 이메일, ISO 날짜, 국가 코드처럼 표준 문법이 필요한 필드를 표시하세요. 일반 랜덤 문자열은 그 계약을 만족하지 않습니다. 비밀값 필드도 따로 표시해 이 픽스처 흐름에서 제외합니다.

  2. 2단계

    운영 값을 변형하지 말고 독립적으로 대체하기

    필드 이름과 구조 관계만 남긴 빈 픽스처에서 시작합니다. 이름을 섞거나 계정 번호를 자르거나, 위협 검토 없이 이메일을 해시하거나, 실제 레코드의 희귀한 자유 텍스트를 남기지 마세요. 대체값을 독립적으로 만들어 다른 복사 필드와 조합해 사람이나 테넌트를 다시 식별할 수 없게 합니다.

  3. 3단계

    제한된 대표 정상값 생성하기

    문서화된 포함 범위와 고정 소수 간격에는 숫자 모드를 사용합니다. 일반 라벨이나 모의 키에는 문자열 모드를 사용하고 필요한 최소 문자 집합을 고른 뒤, 용도 표시가 필요하면 fixture_ 접두사를 붙이고 한 묶음 안에서만 고유값을 요구합니다. UUID 필드는 UUID 생성기를, 비밀번호 정책 테스트는 전용 비밀번호 도구를 사용하세요.

  4. 4단계

    경계값과 잘못된 값을 의도적으로 추가하기

    대표 정상 행을 만든 다음 정확한 최솟값·최댓값, 관련 있는 빈 값이나 null, 고유 필드 중복 하나, 최대 길이를 넘는 문자열, 지원하지 않는 유니코드나 구분자, 숫자 범위 바로 밖의 값을 추가합니다. 랜덤 생성만으로는 검증 동작을 정의하는 사례를 만나지 못할 수 있으므로 이 표를 대신할 수 없습니다.

  5. 5단계

    정확한 대상 형식으로 내보내고 검증하기

    다음 단계와 맞을 때 배열은 JSON, 1열 데이터는 CSV를 선택하고 완전한 레코드 구조에 값을 넣습니다. 실제 파서나 스테이징 가져오기를 실행하세요. 눈으로 맞아 보이는 것에 그치지 말고 UTF-8, CSV 인용, 소수 정밀도, JSON 숫자 범위, null 표현, 열 순서, 고유성 제약을 확인합니다.

  6. 6단계

    안정적인 픽스처와 재생성 조건 기록하기

    스냅샷이나 단언이 정확한 값을 기대하면 테스트 실행마다 생성하지 말고 검토한 결과를 버전 관리에 저장합니다. 스키마 버전, 생성 설정, 직접 추가한 경계 사례, 허용·거부 예상 행, 재생성 조건을 기록하세요. 실행 중 랜덤성은 확률 동작을 직접 검증하고 정확한 값 대신 불변 조건을 단언하는 테스트에만 남깁니다.

예시

공유 가능한 주문 가져오기 픽스처 만들기

입력

스키마: orderKey 문자열 12자, quantity 정수 1~20, unitPrice decimal(8,2) 0.01~999.99, customerId UUID, 파일 안에서 orderKey 고유

출력

fixture_ 라벨, 범위 안 수량·가격, 고정 생성 UUID를 가진 정상 레코드 10개와 수량 0·21, 가격 0.00·1000.00, 중복 orderKey, 빈 customerId, 초과 길이 라벨, 잘못된 CSV 인용을 각각 넣은 별도 행

흔한 실수

운영 내보내기를 그 자리에서 익명화하기

부분 마스킹은 희귀 조합, 내부 ID, 타임스탬프, 자유 텍스트, 레코드 관계를 남겨 식별 가능성을 유지할 수 있습니다. 검토된 익명화 프로그램이 입증되지 않았다면 스키마에서 합성 행을 새로 만드세요.

랜덤 정상값을 전체 커버리지로 간주하기

범위 안 표본은 최솟값, 최댓값, 바로 밖의 값, 중복, 빈 값, 인코딩, 파서 실패를 증명하지 않습니다. 대표 픽스처 옆에 이름이 붙은 경계 매트릭스를 유지하세요.

정확한 출력 테스트 안에서 새 값 생성하기

매번 새 난수를 쓰면 스냅샷과 예상 페이로드가 바뀝니다. 한 번 생성해 저장하거나, 테스트가 반복 가능한 수열을 의도적으로 요구할 때는 문서화된 시드 기반 테스트 라이브러리를 사용하세요.

형식이 있는 필드에 일반 문자열 사용하기

랜덤 영숫자 본문은 UUID 버전, 이메일 문법, 날짜 달력, 체크섬, 국가 코드를 검증하지 않습니다. 형식을 아는 생성기를 쓰고 잘못된 형식도 명시적으로 테스트하세요.

생성된 픽스처 문자열을 보안 토큰이라고 부르기

픽스처 도구는 형태, 한 묶음 안의 고유성, 출력에 초점을 둡니다. 비밀값에는 이 흐름이 제공하지 않는 정책, 엔트로피 검토, 보호된 표시, 저장, 교체, 폐기가 필요합니다.

자주 묻는 질문

합성 데이터는 자동으로 익명인가요?

실제 레코드의 식별값이나 관계를 보존하지 않고 독립적으로 만들었을 때만 그렇게 볼 수 있습니다. 공유 전 자유 텍스트, 타임스탬프, 내부 ID, 희귀 분류, 필드 조합을 검토하세요.

모든 테스트가 랜덤 데이터를 사용해야 하나요?

아닙니다. 안정적인 단위·통합·스냅샷 테스트는 명시적 예상 결과가 있는 커밋된 픽스처가 보통 더 낫습니다. 실행 중 랜덤성은 실패 시 시드나 정확한 입력을 보존하고 불변 조건을 확인하는 속성 기반·퍼즈 테스트에 적합합니다.

대표값은 몇 개 생성해야 하나요?

일반 조합과 컬렉션 동작을 확인할 만큼만 만들고 작은 명시적 경계 매트릭스를 추가하세요. 랜덤 행을 늘리는 것은 신중히 선택한 최소·최대·중복·빈 값·잘못된 형식·인코딩 사례를 대체하지 못합니다.

중복 없는 출력이면 데이터베이스 고유 제약을 만족하나요?

한 번 생성한 묶음과 설정된 값 공간 안에서만 중복을 막습니다. 다른 묶음은 같은 값을 만들 수 있고 동시 삽입도 충돌할 수 있으므로 실제 제약은 데이터베이스가 보장해야 합니다.

내보낸 픽스처를 공개해도 되나요?

완성된 전체 파일을 다시 검토하세요. 생성값은 합성이지만 주변 주석, 파일명, 스키마 필드, 복사한 페이로드 일부, 자격 증명, URL, 메타데이터가 내부 정보를 드러낼 수 있습니다.