작은 프로젝트에서 테스트를 어디까지 짜야 하는가

사이드 프로젝트를 하다 보면 테스트를 어디까지 짜야 하는지 항상 애매하다. 너무 안 쓰면 나중에 리팩터링할 때 두렵고, 너무 많이 쓰면 기능 하나 추가하는 데 테스트 수정이 두 배로 걸린다.

먼저 깨지면 안 되는 것을 정한다

테스트를 어디에 쓸지 결정하는 기준은 간단하다. "이게 깨지면 사용자가 바로 피해를 입는가?" 이 질문에 예스이면 테스트를 쓴다.

• 인증/인가 로직 → 버그나면 데이터 노출
• 결제 금액 계산 → 틀리면 직접 손해
• 데이터 변환 유틸 → 여러 곳에서 쓰이므로 파급이 크다

반면 UI 레이아웃, 색상, 애니메이션은 스냅샷 테스트로 거는 것도 리소스 낭비라고 생각한다. 변경이 잦고 테스트 실패가 실제 버그와 연결되지 않는 경우가 많다.

통합 테스트 하나가 유닛 열 개보다 유용할 때가 있다

// 이런 유닛 테스트보다
test('formatPrice returns string', () => {
  expect(formatPrice(1000)).toBe('1,000');
});

// 이런 통합 테스트가 실제 문제를 더 잘 잡는다
test('POST /orders creates order and returns 201', async () => {
  const res = await request(app)
    .post('/orders')
    .send({ itemId: 'abc', quantity: 2 });
  expect(res.status).toBe(201);
  expect(res.body.total).toBe(2000);
});

formatPrice가 망가지면 통합 테스트도 같이 실패한다. 유닛 하나를 추가로 유지보수할 이유가 없다.

테스트 없이 빠르게 개발하고 나중에 추가하는 패턴

초반에는 인터페이스가 계속 바뀐다. 이 시점에 테스트를 꼼꼼히 쓰면 인터페이스 변경마다 테스트도 뜯어고쳐야 한다. 그래서 나는 프로토타입 단계에서는 거의 쓰지 않고, 기능이 "이 정도면 됐다"싶을 때 핵심 경로에만 붙인다.

추가 타이밍:

• 버그를 하나 고칠 때 → 해당 케이스를 재현하는 테스트를 먼저 쓰고 고친다
• 다른 사람에게 넘기기 전 → 핵심 흐름에 대한 통합 테스트

실용적인 최소 기준

내가 지금 지키는 기준은 이렇다.

영역	테스트 여부
순수 함수 (변환, 파싱, 계산)	유닛 테스트
API 엔드포인트 핵심 경로	통합 테스트
인증 미들웨어	통합 테스트
React 컴포넌트 렌더링	필요할 때만
CSS/스타일	없음

테스트가 없어서 버그가 생기는 게 아니라, 잘못된 위치에 테스트를 써서 유지보수가 힘들어지는 게 더 흔한 문제다.