Claude Code가 작성한 단위 테스트가 쓸모없다고 느끼시나요?

CLAUDE.md 설정:

테스트 및 모킹 제약

1. 기본적으로 모킹 금지

• 명시적 지시 없이는 모킹 파일/객체 생성 금지.
• 거대한 구조적 모킹 대신 실제 구현, 인메모리 DB(SQLite 등), 가벼운 스텁 우선 사용.
• 내부 유틸리티, 네이티브 API, 표준 라이브러리 모킹 금지.

2. 테스트 최소화(YAGNI)

• 사소한 코드(getter, setter, 단순 UI 등)는 테스트 생성 금지.
• 핵심 비즈니스 로직, 복잡한 데이터 변환, 치명적 오류 상태에 집중.
• 테스트 코드와 구현 코드 비율 유지. 테스트 파일이 더 길어지면 멈추고 확인받을 것.

3. 방어적 테스트 강제

• 기존 테스트를 삭제, 비활성화(.skip, .only), 하드코딩해서 통과시키는 것 엄격 금지.
• 코드 변경으로 테스트 실패 시, 테스트를 수정해 숨기지 말고 구현 로직을 수정할 것.

Claude에게 'fake' 대신 'mock'을 쓰라고 지시하는 건, 인간들이 fake와 mock 사이에서 고민할 때 흔히 저지르는 실수와 같은 맥락이라고 생각함. 다들 mock이 정확히 뭘 위한 건지 이해를 못 하거든.

mock은 단위와 의존성 사이의 계약, 즉 API 계약에 정의된 기대치를 설정하기 위한 거임. 예를 들어, 의존성의 API가 특정 형태의 데이터로 정확히 한 번 호출되어야 한다는 계약이 있다면, 그걸 단언(assert)하기 위해 mock을 쓰는 거지.

사람들이 삽질하는 지점은 mock을 다음 두 가지 방식으로 잘못 쓸 때임:

• '실제' 의존성 구현과의 '결합'을 피하려고 mock을 쓰는 경우. 즉, 테스트 중인 구현에 대한 지식을 바탕으로 mocking API를 이용해 즉석에서 fake를 만드는 건데, 이건 결국 시스템의 동작이 아니라 mock의 동작을 테스트하는 꼴이 됨.

• 테스트 대상 단위와 의존성 사이의 계약에는 명시되지 않았지만, 현재 구현에서는 맞다고 알고 있는 기대치를 mock에 설정하는 경우. 예를 들어, API 계약에는 명시되지 않았는데 mock 메서드가 특정 횟수만큼 호출될 거라고 기대치를 잡는 식임. 사람들이 mock을 fake처럼 쓸 때 100% 발생하는 문제고, 제대로 쓸 줄 아는 사람들도 mock에 뭘 인코딩하는지 깊게 생각 안 하면 자주 저지르는 실수임.

사람들은 테스트 단언(assertion)에서도 똑같은 실수를 함. 예를 들어, 아이템 컬렉션을 반환하는 API에서, API가 반환 순서를 보장하지 않는데도 순서에 의존하는 단언을 작성하는 거지. 단위 테스트를 혐오하는 사람들은 다 이런 코드를 본 적이 있을 거임. 뭐 하나만 바꿔도 테스트를 다 뜯어고쳐야 하니까, 테스트가 아무런 유용한 신호도 주지 못하는 상태가 되는 거임.

Claude에게 mock의 목적이 뭔지 상기시켜 주고, 다른 모든 상황에서는 실제 의존성을 쓰거나 그게 안 되면 적절한 fake를 쓰라고 가이드하면, Claude는 거의 항상 올바르게 작동할 거임. 굳이 mock을 만들라고 일일이 지시할 필요도 없어짐.

뮤테이션 테스트를 시키셈.

야 이 녀석아, 테스트를 테스트하려고 테스트 안에 테스트를 넣었어.