Featured image of post [UnitTesting] 00. 단위 테스트, 왜 다시 배워야 하는가

[UnitTesting] 00. 단위 테스트, 왜 다시 배워야 하는가

테스트가 있어도 프로젝트가 느려지는 이유는 테스트가 없어서가 아니라 잘못된 테스트가 많기 때문입니다. 12편에 걸친 이 시리즈 전체의 동기와 상세 커리큘럼, 각 편이 다음 편에 왜 필요한지까지 자세히 함께 정리합니다.

00. 단위 테스트, 왜 다시 배워야 하는가

“테스트를 작성하고 있는데도 프로젝트가 점점 느려집니다.” 이 말은 테스트가 부족하다는 뜻이 아닙니다. 대부분은 테스트가 많지만 잘못 만들어져 있다는 뜻입니다. 이 시리즈는 “테스트를 쓸 것인가 말 것인가"가 아니라, 어떤 테스트가 프로젝트를 실제로 지속 가능하게 만드는가를 다룹니다.

이 시리즈가 해결하려는 문제

단위 테스트를 도입한 팀에서 반복적으로 나타나는 패턴이 있습니다. 초기에는 테스트가 빠르게 늘어나고 자신감도 함께 커집니다. 그런데 몇 달이 지나면 리팩터링 한 번에 테스트 수십 개가 깨지고, 기능 하나를 바꿀 때마다 관련 없어 보이는 테스트까지 손봐야 하는 상황이 옵니다. 결국 팀은 “테스트 유지비가 너무 크다"며 테스트를 줄이거나, 반대로 “커버리지 90%“라는 숫자만 쫓다가 아무것도 검증하지 않는 테스트를 양산합니다.

두 결과 모두 같은 원인에서 나옵니다. 테스트를 코드와 동일한 설계 대상으로 다루지 않았기 때문입니다. 좋은 프로덕션 코드에 원칙이 있듯, 좋은 테스트에도 원칙이 있습니다. 이 시리즈는 그 원칙을 12편에 걸쳐 체계적으로 정리합니다.

커리큘럼 구성

flowchart TD
  subgraph P1["기초: 목표와 정의"]
    C1["1. 단위 테스트의 목표"]
    C2["2. 단위 테스트란 무엇인가"]
    C3["3. 단위 테스트의 구조"]
  end
  subgraph P2["핵심: 좋은 테스트 만들기"]
    C4["4. 좋은 테스트의 4대 요소"]
    C5["5. 목과 테스트 취약성"]
    C6["6. 단위 테스트의 세 가지 스타일"]
    C7["7. 가치 있는 테스트로 리팩터링"]
  end
  subgraph P3["확장: 통합 테스트"]
    C8["8. 통합 테스트"]
    C9["9. 목 사용의 모범 사례"]
    C10["10. 데이터베이스 테스트"]
  end
  subgraph P4["정리: 안티패턴"]
    C11["11. 흔한 안티패턴"]
  end
  P1 --> P2 --> P3 --> P4
제목이 편이 필요한 이유
1단위 테스트의 목표“왜 테스트를 짜야 하는가"에 답이 없으면 이후 모든 판단 기준이 흔들린다
2단위 테스트란 무엇인가고전파/런던파 정의를 모르면 3–9편의 “목을 언제 쓸지” 논의를 따라갈 수 없다
3단위 테스트의 구조AAA 패턴과 픽스처를 정리해야 이후 예제 코드를 읽는 부담이 줄어든다
4좋은 테스트의 4대 요소이후 모든 편이 “이 선택이 4대 요소 중 무엇을 얻고 무엇을 잃는가"로 판단한다
5목과 테스트 취약성4대 요소 중 리팩터링 내성이 가장 자주 깨지는 지점이 목이다
6단위 테스트의 세 가지 스타일스타일 선택이 5편의 목 사용 빈도를 직접 결정한다
7가치 있는 테스트로 리팩터링1–6편에서 다룬 원칙을 기존 테스트 스위트에 적용하는 절차
8통합 테스트단위 테스트만으로 검증할 수 없는 영역(경계, 설정, 인프라)이 있다
9목 사용의 모범 사례통합 테스트에서는 목을 쓰는 기준이 단위 테스트와 다르다
10데이터베이스 테스트가장 흔한 프로세스 외부 의존성인 DB를 구체적으로 다룬다
11흔한 안티패턴1–10편의 원칙을 거꾸로 적용해, 실무에서 반복되는 실수를 진단표로 정리

학습 결과

이 시리즈를 완주하면 다음을 할 수 있게 됩니다.

  • 테스트 코드 리뷰에서 “이 테스트가 좋은 테스트인가"를 4대 요소(회귀 방지, 리팩터링 내성, 빠른 피드백, 유지보수성) 기준으로 판단할 수 있다.
  • 목(mock)을 언제 쓰고 언제 피해야 하는지, 관리 의존성과 비관리 의존성을 구분해 설명할 수 있다.
  • 커버리지 숫자에 의존하지 않고 테스트 스위트의 실질적 품질을 평가할 수 있다.
  • 기존에 작성된 취약한 테스트를 가치 있는 테스트로 리팩터링하는 절차를 적용할 수 있다.
  • 단위 테스트와 통합 테스트의 역할을 구분하고, 데이터베이스가 포함된 테스트를 설계할 수 있다.

참고 문헌 및 출처(추천)

이 시리즈는 특정 책의 장별 요약이 아니라, 아래 여러 출처의 개념을 재구성해 독자적으로 서술합니다. 특정 프레임워크(예: “좋은 테스트의 4대 요소”)를 소개할 때는 원 제안자를 본문에서 그때그때 명시합니다.

  • Vladimir Khorikov, 『Unit Testing: Principles, Practices, and Patterns』(Manning, 2020) — “좋은 테스트의 4대 요소”, “관리/비관리 의존성” 프레임워크의 원 출처
  • Gerard Meszaros, 『xUnit Test Patterns: Refactoring Test Code』(2007) — 목/스텁/페이크 등 테스트 더블 용어 분류의 원 출처
  • Steve Freeman, Nat Pryce, 『Growing Object-Oriented Software, Guided by Tests』(2009) — “런던파(mockist)” 스타일의 원 출처
  • Kent Beck, 『Test-Driven Development: By Example』(2002) — “고전파(classicist)” TDD의 원 출처
  • Martin Fowler, “Mocks Aren’t Stubs”(martinfowler.com, 2007) — 테스트 더블 종류 구분

다음 글