SQL·테스트 데이터
실제 데이터 없이 같은 테스트 데이터 재현하기
사용할 도구
새로고침 후 버그가 사라져도 수정이 아니라 데이터 변경일 수 있습니다. 매번 랜덤인 샘플은 재현 조건을 잃게 합니다. Seed 생성으로 같은 설정을 재현하고 실제 사용자 정보를 복사하지 않는 작은 가상 데이터를 만드세요.
세 행·네 열 가상 목록부터
3행·Seed42·JSON을 고르고 id=integer, name=name, active=boolean, email=email 순으로 정의하세요. 현재 구현은 아래 값을 만들며 고정 이름 후보·example.test 가상 주소를 사용하고 실제 인물을 조회하지 않습니다.
[{"id":1,"name":"Haru","active":false,"email":"user1@example.test"},{"id":2,"name":"Ren","active":false,"email":"user2@example.test"},{"id":3,"name":"Mina","active":false,"email":"user3@example.test"}]같은 조건으로 다시 생성해 같은지 보세요. 이름은 특정 사용자를 모델링하지 않습니다. 테스트임을 표시하고 운영 알림으로 보내지 마세요. 가상 주소와 시험 환경 발송 비활성화는 별도 대책입니다.
열 순서도 재현 조건
Seed43이면 둘째Haru·셋째Aoi/active true이고 첫행은 같습니다. Seed 변경이 모든 셀 변경은 아니며 integer·email은 행 번호라 유지됩니다. 난수형과 행 번호형을 나눠 보세요.
난수를 쓰는 열 추가·재정렬은 소비 순서를 바꿔 같은Seed의 이후 값도 바꿀 수 있습니다. 열명·타입·순서·개수·형식을 함께 기록하세요. 향후 생성기 변경도 있으므로 장기 회귀는 필요한 결과 자체를 Fixture로 보관할 수 있습니다.
JSON·CSV·SQL은 표현이 다름
CSV는 헤더·행, SQL은 지정 표INSERT입니다.JSON boolean이CSV에서true/false로 보여도 읽는 쪽이boolean으로 복원한다는 보장은 없습니다. 모양뿐 아니라 받는 도구 타입을 확인하세요.
SQL은 텍스트만 만들며 제약·기본값·외래키를 조사하지 않습니다. 열명이 같다고 운영 삽입 허가는 아닙니다. 최소 테스트 스키마를 만들고 외부 알림·과금 흐름과 분리하세요.
랜덤 몇 행만으로 경계가 채워지지 않음
Seed 42에서는 active가 세 행 모두 false이므로 true 상태를 검증한 것은 아닙니다. 긴 이름, 빈 문자열, NULL, 따옴표, 이모지, 최대값이 우연히 모두 나오지는 않습니다. constant 타입이나 별도의 명시적인 Fixture로 필요한 경계를 준비하세요. 무작위 예시와 의도적으로 설계한 경계 사례는 역할이 다릅니다.
행 개수의 경계도 의도적으로 시험하세요. 생성기는 1~1,000행을 지원하므로 빈 목록은 테스트의 빈 배열 등으로 준비합니다. 페이지 전환을 보려면 정확히 한 페이지와 한 개 초과를 선택하세요. 많이 만드는 것보다 어떤 경계를 검사할지 정하는 것이 중요합니다.
재현 난수는 비밀용이 아님
같은 Seed로 재현할 수 있다는 점은 테스트에 유용하지만 비밀값 생성에는 적합하지 않습니다. 생성한 문자열이나 이메일을 인증 토큰이나 실제 계정으로 사용하지 마세요. 비밀값은 암호학적 난수 도구로 생성하고, 그렇게 만든 비밀도 재현용 데이터에 붙이지 마세요.
버그 보고에는 열 정의, Seed, 행 수, 출력 형식, 기대 결과와 실제 결과를 모으고 최소 재현 사례로 줄이세요. 많은 무작위 데이터로 시험했다는 설명보다 이 세 행에서 문제가 발생한다는 설명이 더 명확합니다. 어떤 입력이 문제였는지 알아야 수정 후 회귀 테스트도 구체적으로 할 수 있습니다.
무작위로 발견한 실패를 고정 재현 예로 바꾸기
많은 무작위 데이터로 한 번 화면이 깨졌다면 다른 Seed에서 성공해도 고쳐진 것은 아닙니다. Seed, 열 정의와 순서, 행 수, 형식을 남겨 먼저 재현하세요. 생성기 버전에 따라 수열이 달라질 수 있어 장기 회귀 테스트에는 실패를 만든 가상 행 자체를 고정 Fixture로 보관하는 방법이 유용합니다.
다음으로 무관한 행이나 열을 줄여도 실패하는지 보세요. 천 행 문제도 표시 이름이 같은 두 행으로 줄거나 개수 경계 바로 위에서만 발생할 수 있습니다. 그 경우 경계 전후 개수를 고정하세요. 난수는 조합 탐색에, 작은 Fixture는 발견 조건 설명에 적합합니다. 최소화하면서 실패 원인까지 없애지 않도록 구별해야 합니다.
가상 이름과 이메일은 실제 행동이나 분포를 나타내지 않습니다. 성능·용량 시험에는 길이, 값의 종류, 중복 정도 같은 특징이 필요할 수 있어 별도로 정해야 합니다. 단순 타입이 부족하면 한계를 남기고 생성 행 수만으로 시험이 충분하다고 판단하지 마세요.