단위 테스트 목표

단위 테스트의 목표는 버그를 없애는 게 아니야. 소프트웨어 개발 속도를 지속 가능하게 유지하는 것이지. 이게 1장의 핵심이고, 이걸 잘못 잡으면 테스트를 아무리 많이 써도 오히려 짐이 돼.

단위 테스트는 이미 업계 표준이 됐어. 테스트 없는 팀이 이상하게 보이는 시대야. 근데 실무에서 보면 테스트가 수백 개인데도 뭔가 바꿀 때마다 불안한 팀이 많거든. 이유가 뭐냐면, 테스트를 쓰는 것 자체가 목표가 돼버린 거야. 수단이 목적으로 바뀐 거지. 나쁜 테스트 스위트는 없는 것보다 나쁠 수 있어. 유지비용은 나가는데 진짜 버그는 못 잡는 상황이 되거든.

그래서 목표를 다시 잡아야 해. 테스트는 코드베이스가 커져도 개발 속도가 무너지지 않게 받쳐주는 역할이야. 테스트가 없으면 처음엔 빠르지만, 기능 하나 추가할 때마다 드는 비용이 기하급수적으로 늘어나. 테스트는 그 증가 곡선을 눌러줘. 결국 테스트의 목적은 **"변경에 자신 있는 코드베이스"**야. 깨질까봐 겁나지 않게.

커버리지 지표도 오해가 많은 영역이야. 커버리지 100%가 좋은 테스트를 보장하지 않아. 코드가 얼마나 실행됐는지를 알려줄 뿐이고, 그 실행이 의미 있는 검증인지는 알려주지 못하거든. 단언(assertion)이 하나도 없는 테스트로도 커버리지를 100%로 만들 수 있어. 커버리지를 목표로 잡는 순간 숫자는 높아지고 테스트는 텅 비어가. 커버리지는 보조 지표야. 낮으면 문제라는 신호지만, 높다고 안심하면 안 돼.

그럼 진짜 좋은 테스트 스위트는 어떤 거냐면, 네 가지를 갖춰. 소스코드와 함께 관리되고 CI에서 돌아가야 하고, 비즈니스 로직에 집중해야 하고, 자주 깨지지 않아야 하고, 신뢰할 수 있어야 해. 통과하면 진짜 통과, 실패하면 진짜 문제. 이 신뢰가 무너지면 빨간 불이 켜져도 "또 거짓 양성이겠지"하고 무시하게 되거든. 그 순간 테스트는 소음이 돼.

---

정리

1장 읽고 기억할 거 세 가지:

1. **테스트의 목표는 "버그 제거"가 아니라 "지속 가능한 개발 속도"**야. 목표가 틀리면 테스트가 아무리 많아도 짐만 돼
2. 커버리지는 보조 지표야. 낮으면 문제, 높다고 안심하면 안 돼. 수치 목표로 잡는 순간 의미를 잃어
3. 좋은 테스트는 자주 안 깨지고, 실패할 때는 진짜 문제가 있어야 해. 이 신뢰가 전부야