Testing Pyramid & Isolation Physics

1. Overview

테스트 피라미드 및 격리 물리학(Testing Pyramid & Isolation Physics, TPI)은 수만 번의 테스트가 1분 이내에 완료되도록 설계하는 고효율 품질 공학이자, 테스트 대상 코드와 외부 세상을 수리적으로 절연(Isolation)하여 '결과가 항상 동일함'을 보장하는 신뢰의 물리학입니다.

학습자는 실행 속도가 빠르고 비용이 저렴한 **단위 테스트(Unit Test)**의 물리적 기반과, 시스템 전체의 연동을 확인하는 E2E 테스트의 수리적 결합 차이를 배웁니다. 특히, 가용성이 불투명한 하드웨어(DB, API)를 가상의 논리 모델로 대체하는 Mocking 및 Stubbing의 물리적 수순을 익힙니다. 이를 통해 개발 속도를 늦추지 않으면서도 시스템의 모든 구석을 완벽하게 보호하는 하이엔드 테스트 전략 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Testing Pyramid Distribution: 단위/통합/E2E 테스트의 수리적 황금 비율(7:2<1> 등)
• Test Isolation Principles: 전역 상태 및 DB 의존성 물리적 제거 수순
• Test Doubles: Dummy, Stub, Spy, Mock, Fake의 수리적 전하(역할) 구분
• Speed & Stability Correlation: 테스트 실행 시간($T$)과 개발 피드백 관성의 반비례 물리학
• Clean Test Suites: 깨지기 쉬운(Brittle) 테스트를 방지하는 물리적 명세 규칙

Out-of-Scope

• 구체적인 테스트 주도 개발(TDD) 순환 수순 (09-02-02 AAA 영역에서 분담)
• 보안 취약점 진단을 위한 동적 스캐닝 상세 (09-02-03 Scanning 영역에서 분담)

Boundaries

• TPI vs. AAA Pattern: TPI가 '어떤 종류의 테스트를 얼마큼, 어떻게 격리해서 배치할 것인가'라는 거시적 배치 물리에 집중한다면, AAA(09-02-02)는 '개별 테스트 코드의 내부 구조'라는 미시적 논리에 집중합니다.

3. Counterexample

• 단순히 "테스트 많이 짜기"라 설명하는 것은 TPI 학습이 아닙니다. 왜 E2E 테스트의 비중이 높아졌을 때 시스템 전체의 빌드 시간($Build Time$)이 기하급수적으로 늘어나고 'Flaky(간헐적 실패)' 현상이 하드웨어 노이즈로 인해 발생하는지 수리적으로 증명할 수 있어야 하며, 단위 테스트에서 실제 DB를 사용하는 것이 왜 '격리 물리'를 파괴하고 테스트의 병렬 실행을 불가능하게 만드는지 논증하지 못한다면 TPI의 정수를 이해하지 못한 것입니다.

4. Prerequisites

• Software Construction & Code Physics (Basic): 09-01-04의 클린 코드 및 함수 격리 이해가 필수입니다.
• Operating Systems & System Mechanics (Recommended): 프로세스 독립성 및 파일 I/O 오버헤드 이해가 권장됩니다. (03-01-XX)

5. Learning Map

1. The Shape of Quality: 테스트가 많다고 좋은 것이 아님을 인지하고, 피라미드 형태의 수리적 균형을 이해합니다.
2. Cutting the Cord: 실제 하드웨어 세계와의 연결을 끊고, 순수한 논리만 남기는 격리(Isolation)를 배웁니다.
3. Ghost Actors: 데이터베이스나 외부 서버 대신 정해진 대답만 하는 유령 배우(Mock)들을 배치합니다.
4. Instant Confidence: 코드 한 줄을 고칠 때마다 수천 개의 테스트가 빛의 속도로 내리는 축복을 경험합니다.

6. Learning Topics

Basic

Core: 테스트 피라미드의 비중과 가치 (Pyramid Foundations)

• Why to Learn: 한정된 시간 안에 가장 큰 품질 보증 효과를 수리적으로 얻기 위해서입니다.
• What to Learn:
  • Unit Tests: 클래스/함수 단위의 초고속 물리 검증
  • Integration Tests: 모듈 간의 협력 수리 정합성
  • E2E Tests: 사용자 시나리오 기반의 종단 간 물리 흐름
• How to Learn:
  • 동일한 로직을 단위 테스트와 E2E 테스트로 각각 작성하고, 실행 시간($ms$)과 작성 비용($min$)을 비교 측정 실습
  • 피라미드가 아닌 '아이스크림 콘(역피라미드)' 구조의 위험성 수치 분석
• Implement: 테스트 유형별 개수를 입력하여 현재 프로젝트의 '품질 형상 지수'를 도출하는 PyramidScanner

Recommended

Core: 테스트 격리와 부작용 통제 (Isolation Physics)

• Why to Learn: 다른 테스트나 환경 변수가 내 테스트 결과에 노이즈를 주지 않게 하기 위해서입니다.
• What to Learn:
  • Global State Pollution: 전역 변수가 테스트 간 간섭을 일으키는 물리적 경로
  • Temporal Isolation: 현재 시간($Time$) 의존성을 수리적으로 주입(DI)받아 제어하는 법
  • System Resource Scoping: 특정 폴더나 포트를 테스트별로 격리하여 사용하는 수순
• How to Learn:
  • 병렬로 실행했을 때만 실패하는 '간섭 버그'를 재현하고, 상태 초기화($Setup/Teardown$)를 통해 물리적 완충 실습
  • 하드코딩된 new Date()를 고정된 수치로 대체했을 때 테스트 안정성($A$)이 100%에 수렴하는지 확인
• Implement: 테스트 실행 전후로 전역 상태의 변화 유무를 감시하는 StateIntegrityGuard

Practical

Core: 테스트 더블의 유형과 활용 (Mocking Mechanics)

• Why to Learn: 아직 만들어지지 않았거나 너무 느린 백엔드 하드웨어를 기다리지 않고 개발하기 위해서입니다.
• What to Learn:
  • Stubs vs Mocks: 상태 검증과 행위 검증의 수리적 의도 차이
  • Fake Objects: 인메모리 DB와 같이 가볍지만 실제처럼 동작하는 하드웨어 가상화
  • Spy Mechanics: 특정 함수가 몇 번 호출되었는지 기록하는 수치적 감시
• How to Learn:
  • 외부 결제 API 호출부를 Mock으로 대체하여, "잔액 부족"일 때와 "네트워크 오류"일 때의 수리 시나리오를 즉각 검증 실습
  • 과도한 Mocking이 실제 하드웨어 연동 시 '거짓 양성($False Positive$)'을 유발하는 물리적 한계점 연구
• Implement: 입력한 인터페이스의 모든 메서드를 자동 Stub화하는 MockScaffold 코드

Advanced

Core: 테스트 가용성과 Flaky 제어 (Stability Governance)

• Why to Learn: "가끔 실패하는" 테스트는 공포를 유발하며 시스템 전체의 신뢰 물리를 파괴하기 때문입니다.
• What to Learn:
  • Flakiness Analysis: 동기화 지연, 비결정적 순서 등 노이즈의 수치적 근원 식별
  • Test Retries vs Root Cause: 무의미한 재시도가 감추는 물리적 부패의 위험성
  • Contract Testing: Mock이 실제 서버와 일치하는지 보장하는 '계약 수리' 수순
• How to Learn:
  • 특정 테스트가 100번 중 5번 실패할 때, 네트워크 지연($Latency$) 수치와 실패 확률의 상관관계 분석 실습
  • CDC(Consumer Driven Contracts) 도구를 사용하여 Mock의 유효성을 실시간으로 동기화하는 물리 체계 구축
• Implement: 테스트 실행 결과의 역사적 안정성을 점수화하여 '격리 등급'을 매기는 FlakyDetective

7. Terminology

8. References

Primary

• [P2] SWEBOK v4.0 - Software Testing / Test Levels & Techniques — Testing standards.
• [P5] SFIA v9 - Software Engineering / Testing — Professional skills.

Secondary

• [xUnit Test Patterns] Gerard Meszaros — The source of test doubles.
• [Software Engineering at Google] Titus Winters — Chapters on testing and flaky tests.

Industry

• [The Practical Test Pyramid] Ham Vocke (MartinFowler.com) — Modern industry application.
• [Martin Fowler: Mocks Aren't Stubs] — Definitive distinction.

9. Final Checklist

Primary

• '단위 테스트'가 '통합 테스트'보다 하드웨어 리소스 관점에서 왜 물리적으로 압도적 속도를 내는지 설명 가능한가? (P2)
• '테스트 피라미드' 붕괴가 전체 소프트웨어 인도 속도($Delivery Velocity$)에 미치는 수리적 감쇄 효과를 기술할 수 있는 가? (P2)

Secondary

• '상태 기반 검증($State-based$)'과 '행위 기반 검증($Interaction-based$)'의 물리적 차이를 Mock과 Stub의 사용 사례로 소통 가능한가?
• 테스트 격리 파괴 시 발생하는 '지저분한 공유 상태'가 디버깅 시간을 어떻게 수치적으로 가중시키는지 논증할 수 있는 가?

Industry

• 실무 빌드 파이프라인에서 '테스트 커버리지'가 100%임에도 불구하고 대형 장애가 발생하는 물리적 틈새를 찾아 제안할 수 있는 가? (SFIA)
• Docker를 활용한 ephemeral(일회성) DB 테스트 격리 전략이 일반적인 Mocking 대비 갖는 물리적 트레이드오프를 분석할 수 있는 가?