--- id: testing-faker-and-builders title: Test Data — Faker, Object Mother, Builder category: Coding status: draft source_trust_level: B verification_status: conceptual created_at: 2026-05-09 updated_at: 2026-05-09 tags: [testing, fixtures, faker, builder, vibe-coding] tech_stack: { language: "TypeScript", applicable_to: ["Backend", "Web"] } applied_in: [] aliases: [test data builder, factory, object mother, fixture] --- # Test Data — Faker / Mother / Builder > 테스트 fixture 는 (1) 빠르게 만들 수 있어야 하고, (2) **이 테스트가 진짜 신경 쓰는 필드만 명시** 되어야 한다. 나머지는 무관한 디폴트. Object Mother + Builder + Faker 결합이 표준. ## 📖 핵심 개념 - **Faker**: 랜덤 그럴듯한 데이터 (이름, 이메일, 날짜). - **Object Mother**: 자주 쓰는 시나리오에 이름 (`anAdminUser()`, `aPaidOrder()`). - **Builder**: fluent API 로 일부 필드만 override. ## 💻 코드 패턴 ### Faker (faker-js) ```ts import { faker } from '@faker-js/faker'; faker.seed(42); // 재현 가능 const u = { id: faker.string.uuid(), email: faker.internet.email(), name: faker.person.fullName(), signedUpAt: faker.date.past({ years: 1 }), }; ``` ### Object Mother ```ts // test/mothers/userMother.ts export function anAdminUser(over: Partial = {}): User { return { id: faker.string.uuid(), email: faker.internet.email(), role: 'admin', verified: true, ...over, }; } export function anUnverifiedUser(over: Partial = {}) { return anAdminUser({ role: 'viewer', verified: false, ...over }); } // 사용 test('admin can ban', () => { const admin = anAdminUser(); expect(canBan(admin)).toBe(true); }); test('unverified cannot post', () => { const u = anUnverifiedUser(); expect(canPost(u)).toBe(false); }); ``` ### Builder (fluent) ```ts class UserBuilder { private u: User = anAdminUser(); // mother base withEmail(e: string) { this.u.email = e; return this; } withRole(r: Role) { this.u.role = r; return this; } unverified() { this.u.verified = false; return this; } build() { return { ...this.u }; } } const u = new UserBuilder().withEmail('a@a.com').unverified().build(); ``` ### Test factory + DB ```ts // test/factories/userFactory.ts export async function createUser(over: Partial = {}) { const u = anAdminUser(over); return await db.users.insert(u); } test('login with seeded user', async () => { const u = await createUser({ email: 'login@test.com' }); // ... }); ``` ### 명시적으로 신경 쓰는 필드만 ```ts // ❌ 모든 필드 직접 const u = { id: '1', email: 'a@a.com', name: 'A', role: 'admin', ... 20 fields }; // 어느 것이 이 test 와 관련 있는지 모름 // ✅ 신경 쓰는 것만 const u = anAdminUser({ email: 'login@test.com' }); // 이 test 는 email 만 신경 — 명확 ``` ## 🤔 의사결정 기준 | 상황 | 패턴 | |---|---| | 단순 객체, 1-2 field 다양 | mother + over object | | 많은 필드 / 다양한 시나리오 | Builder | | 랜덤 입력 (property test) | Faker + fast-check | | DB seeding | Factory (DB insert 포함) | | 복잡 그래프 (User → Posts → Comments) | nested factory or fishery 라이브러리 | ## ❌ 안티패턴 - **fixture 안에 모든 필드 명시**: 변경 시 모든 test 깨짐. mother 로 디폴트. - **공유 mutable fixture**: test 가 mutate 하면 다른 test 영향. 항상 새 인스턴스. - **Faker seed 안 고정**: 매 실행 다른 데이터 → flaky. 전역 seed 또는 deterministic 데이터. - **글로벌 DB seed 의존**: test 순서 의존. 각 test 가 자기 데이터. - **가짜 같지 않은 데이터** (`name: 'test'`, `email: 'a@a.com'`): edge case 안 잡힘. - **거대 builder 체인** (10+ 메서드): 그냥 시나리오별 mother 가 더 명확. ## 🤖 LLM 활용 힌트 - 매 테스트 fixture: "이 테스트가 신경 쓰는 필드만 명시. 나머지는 mother default" 강제. - Faker seed 고정 (top-level beforeAll). ## 🔗 관련 문서 - [[Testing_Test_Pyramid]] - [[Testing_Snapshot_Patterns]]