[UnitTesting] 02. 단위 테스트란 무엇인가: 고전파와 런던파

단위 테스트의 정의를 두고 고전파(classicist)와 런던파(mockist)라는 두 학파가 갈립니다. '단위'를 클래스로 볼지 협력 객체 전체로 볼지에 따라 목 사용 전략이 완전히 달라지는 이유를 코드로 다룹니다.

[UnitTesting] 03. 단위 테스트의 구조: AAA 패턴과 픽스처

테스트 하나가 여러 단계를 뒤섞어 서술하면 읽는 사람이 의도를 파악하기 어렵습니다. 준비-실행-검증(AAA) 패턴으로 테스트 구조를 통일하고, 픽스처 재사용 판단 기준과 매개변수화 테스트로 코드 중복을 줄이는 실무적인 방법을 다룹니다.

[UnitTesting] 04. 좋은 단위 테스트를 가르는 4대 요소

회귀 방지, 리팩터링 내성, 빠른 피드백, 유지보수성. 이 4가지 요소로 테스트의 좋고 나쁨을 판단하면, '테스트가 있다/없다'가 아니라 '이 테스트가 값어치를 하는가'를 구체적인 코드 예제로 함께 논의할 수 있습니다.

[UnitTesting] 05. 목과 테스트 취약성

목(mock)은 강력하지만 잘못 쓰면 리팩터링 내성을 가장 빨리 갉아먹는 도구입니다. 목/스텁/페이크의 정확한 구분과, 목을 써도 되는 경계(프로세스 외부 의존성, 관리/비관리 의존성)를 코드 예제로 명확히 다룹니다.

[UnitTesting] 06. 단위 테스트의 세 가지 스타일

출력 기반, 상태 기반, 통신 기반 테스트는 같은 로직도 서로 다른 방식으로 검증합니다. 4대 요소 기준으로 비교하면 출력 기반이 가장 견고하지만, 부작용이 있는 코드에는 항상 그대로 적용할 수 있는 것이 아닙니다.

[UnitTesting] 07. 가치 있는 테스트로 리팩터링하기

복잡도와 협력자 수를 두 축으로 코드를 4분면에 배치하면, 어디에 단위 테스트를 집중하고 어디를 통합 테스트나 단순화로 처리할지가 명확해집니다. 1–6편 원칙을 기존 테스트 스위트에 적용하는 구체적인 절차를 다룹니다.

[UnitTesting] 08. 통합 테스트: 언제, 왜 필요한가

단위 테스트만으로는 컨트롤러 영역과 실제 인프라 연동을 검증할 수 없습니다. 통합 테스트의 역할과 트레이드오프, 테스트 피라미드와 트로피 모델을 비교해 단위·통합 테스트 비중을 정하는 구체적인 실무 방법을 다룹니다.

[UnitTesting] 09. 목 사용의 모범 사례

통합 테스트에서는 목을 어디에 걸어야 할까요? 시스템 경계에서 가장 먼 안쪽이 아니라, 애플리케이션 경계에 가장 가까운 지점에 목을 걸어야 하는 이유와 구체적인 배치 기준, 외부 API 실패 재현 방법을 코드 예제로 다룹니다.

[UnitTesting] 10. 데이터베이스 테스트하기

관계형 데이터베이스는 가장 흔한 프로세스 외부 의존성입니다. 인메모리 대체가 위험한 이유, 테스트 간 데이터 격리 전략(트랜잭션 롤백), 스키마 마이그레이션과 테스트를 함께 유지하는 아주 구체적인 실무 방법을 다룹니다.

[UnitTesting] 11. 흔한 단위 테스트 안티패턴

private 메서드 테스트, 도메인 지식 유출, 시스템 시간 직접 의존, 거대 픽스처, 테스트용 프로덕션 분기 등 반복되는 단위 테스트 안티패턴 5가지를 1–10편의 원칙으로 진단하고 개선하며 시리즈를 마무리합니다.