2nd/10_Wiki/Topic_Programming/Coding/Testing_Faker_and_Builders.md

id, title, category, status, source_trust_level, verification_status, created_at, updated_at, tags, tech_stack, applied_in, aliases

id	title	category	status	source_trust_level	verification_status	created_at	updated_at	tags	tech_stack	applied_in	aliases
testing-faker-and-builders	Test Data — Faker, Object Mother, Builder	Coding	draft	B	conceptual	2026-05-09	2026-05-09	testing fixtures faker builder vibe-coding	language applicable_to TypeScript Backend Web		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)

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

// test/mothers/userMother.ts
export function anAdminUser(over: Partial<User> = {}): User {
  return {
    id: faker.string.uuid(),
    email: faker.internet.email(),
    role: 'admin',
    verified: true,
    ...over,
  };
}

export function anUnverifiedUser(over: Partial<User> = {}) {
  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)

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

// test/factories/userFactory.ts
export async function createUser(over: Partial<User> = {}) {
  const u = anAdminUser(over);
  return await db.users.insert(u);
}

test('login with seeded user', async () => {
  const u = await createUser({ email: 'login@test.com' });
  // ...
});

명시적으로 신경 쓰는 필드만

// ❌ 모든 필드 직접
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