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

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

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

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

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

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

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

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

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

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

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

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

[Design 11] Capacity Planning

용량 계획(Capacity Planning)을 트래픽 성장 예측·헤드룸 산정·인스턴스 스케일링 결정으로 잇는 방법론을 다룹니다. Universal Scalability Law로 수평 확장의 한계를, N+1/N+2 헤드룸으로 장애 내성을, USE 메서드로 병목 자원 식별 판단 기준을 정리합니다.

[Design 11] Cost-Performance 분석

클라우드 인스턴스·아키텍처(x86/ARM) 선택을 TCO 관점에서 판단하는 기준을 다룹니다. price-performance 비율 계산법과 On-Demand·Reserved·Savings Plans·Spot 커밋먼트 트레이드오프, 벤더 벤치마크를 자체 워크로드로 재검증해야 하는 이유를 정리합니다.

[Design 11] Event-driven 아키텍처 성능

메시지 브로커 기반 이벤트 통신이 직접 호출 대비 지연시간·처리량을 어떻게 구조적으로 바꾸는지 설명하고, 전달 보장·choreography vs orchestration 트레이드오프로 브로커 도입 여부를 판단하는 기준을 정리합니다.

[Design 11] Load Testing 설계

부하 테스트로 성능 목표(예산·SLO)를 검증하는 설계 결정을 다룹니다. Open/closed 워크로드 모델링과 트래픽 재현성, coordinated omission·percentile 오독 등 결과 해석 함정과 판단 기준을 정리합니다.