TDD, AAA Pattern & State Verification

1. Overview

TDD 및 AAA 패턴과 상태 검증(TDD, AAA Pattern & State Verification, TAS)은 코드의 첫 번째 클라이언트로서 테스트를 활용해 설계를 견인하고, 테스트 코드 자체가 살아있는 명세서(Executable Specification)가 되도록 구조화하는 '테스트 설계 물리학'입니다.

학습자는 실패하는 테스트(Red)를 시작으로 성공(Green)을 거쳐 개선(Refactor)으로 이어지는 Red-Green-Refactor의 물리적 순환 수순을 배웁니다. 특히, 테스트 코드를 준비(Arrange), 실행(Act), 단언(Assert)의 세 영역으로 엄격히 분리하는 AAA 패턴의 수리적 레이아웃을 익힙니다. 이를 통해 단순히 버그를 잡는 것을 넘어, 코드의 설계 의도가 하드웨어에서 어떻게 증명되어야 하는지를 명확히 기술하는 하이엔드 개발 규율 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• TDD Cycle: Red(실패), Green(최소 구현), Refactor(구조 개선)의 물리적 시간차 적용
• AAA Pattern: 테스트 문서의 물리적 위계와 가독성을 위한 논리 구획화
• State-based Verification: 객체의 최종 수치/상태가 기대값과 일치하는지 확인하는 물리 단언
• Assertion Dynamics: Equality, Range, Types, Exceptions 등 수리적 판단 기제
• Testable Design: TDD가 강요하는 '느슨한 결합'의 물리적 필연성 증명

Out-of-Scope

• 테스트 도구(JUnit, Pytest)의 라이브러리 API 사용법 (각 언어 노드에서 분담)
• 대규모 시스템 연동을 위한 테스트 피라미드 비중 설계 (09-02-01 TPI 영역에서 분담)

Boundaries

• TAS vs. TPI: TPI(09-02-01)가 '테스트의 가치와 하드웨어적 격리 배치'에 집중한다면, TAS는 '테스트 코드를 짜는 리듬과 개별 코드의 내부 논리 구조'에 집중하여 구분합니다.

3. Counterexample

• 단순히 "테스트부터 짜기"라 설명하는 것은 TAS 학습이 아닙니다. 왜 Red 단계 없이 짠 테스트가 '테스트 자체의 버그'를 물리적으로 걸러내지 못하는지 수리적으로 증명할 수 있어야 하며, AAA 패턴을 무시하고 Arrange와 Act가 뒤섞인 코드가 왜 미래의 유지보수 개발자에게 인지 부하라는 물리적 노이즈를 주는지 논증하지 못한다면 TAS의 본령을 이해하지 못한 것입니다.

4. Prerequisites

• Software Construction & Code Physics (Basic): 09-01-04의 리팩터링 및 클린 코드 기초 이해가 필수입니다.
• Testing Pyramid & Isolation Physics (Recommended): 09-02-01의 단위 테스트 개념 이해가 권장됩니다.

5. Learning Map

1. Failure First: 실패를 두려워하지 않고, 구현 전에 '요구사항의 수리적 결말'을 먼저 정의합니다.
2. The Minimum Path: 단언을 통과하기 위한 가장 게으른(하지만 확실한) 물리적 코드를 작성합니다.
3. Draft to Masterpiece: 돌아가는 코드를 장인 정신으로 닦아내어 물리적 복잡도를 낮춥니다.
4. Structured Truth: AAA 패턴이라는 튼튼한 그릇에 테스트의 진실을 담아 영원히 보존합니다.

6. Learning Topics

Basic

Core: TDD의 순환 주기와 원칙 (The TDD Rhythm)

• Why to Learn: 버그가 숨어들 틈을 수리적으로 차단하고, 항상 안전하게 코드를 고치기 위해서입니다.
• What to Learn:
  • Red Stage: 기능이 없음을 수리적 실패로 증명하는 물리적 정위치
  • Green Stage: 오직 테스트 통과만을 위한 최소한의 하드웨어 연동 코드
  • One Test at a Time: 한 번에 단 하나의 명제만 물리적으로 검증하는 규칙
• How to Learn:
  • '문자열 계산기'를 만들며, 1단계(공백 입력) 실패 테스트부터 시작해 5분 단위로 사이클을 돌려보는 실습
  • Green 단계에서 '하드코딩'된 정답을 제출했을 때의 쾌감과 그 뒤의 물리적 필연성 이해
• Implement: 현재 작업의 상태(R/G/R)와 다음 행동 지침을 보여주는 간단한 TDDDashboard

Recommended

Core: AAA 패턴과 테스트 레이아웃 (The AAA Standard)

• Why to Learn: 테스트 코드가 복잡해져서 정작 무엇을 테스트하는지 알 수 없는 물리적 혼란을 막기 위함입니다.
• What to Learn:
  • Arrange: 객체 생성, 목 설정 등 실험의 물리적 배경 준비
  • Act: 테스트 대상(SUT)을 찌르는 단 한 줄의 물리적 행동
  • Assert: 기대한 결과 수치와 실제를 수리적으로 비교
• How to Learn:
  • 스파게티처럼 꼬인 기존 테스트 코드를 AAA 주석(Comment)을 기준으로 3부분으로 가위질하여 재배치하는 실습
  • Act 영역이 두 줄 이상일 때, 그것이 왜 '단일 책임 테스트'의 물리 법칙을 위배하는지 논의
• Implement: 주어진 테스트 코드를 분석하여 AAA 구역의 비중을 수치화하는 StructureVisualizer

Practical

Core: 상태 검증과 단언 테크닉 (Assertion Physics)

• Why to Learn: "잘 된다"의 기준을 하드웨어가 오해하지 않도록 정밀한 수리적 잣대를 대기 위해서입니다.
• What to Learn:
  • Primitive vs Object Assert: 데이터 조각과 복합 상태의 물리적 비교 수순
  • Exception Assertion: 시스템이 정해진 규칙대로 물리적 폭발(Error)을 일으키는지 검증
  • Domain Specific Language (DSL): assertThat(actual).isEqualTo(expected)와 같은 인간 친화적 수리 명세
• How to Learn:
  • 복잡한 객체의 필드 10개를 일일이 비교하는 대신, '객체 동등성($Value Object$)' 수리 모델로 한 번에 단언하는 실습
  • 부동 소수점($Float$) 연산 결과 측정 시 '오차 범위(Delta)'의 물리적 필요성 증명
• Implement: 다양한 상황(성공, 실패, 예외)에 대응하는 표준 단언 템플릿 AssertMaster

Advanced

Core: 리팩터링의 정석과 테스트 보호 (Refactoring Safe-haven)

• Why to Learn: 코드를 더 좋게 고치다가 기존 기능을 물리적으로 파괴하는 참사를 방지하기 위함입니다.
• What to Learn:
  • Refactoring without Regret: 테스트라는 안전그물 속에서 수행하는 도수 높은 물리 개조
  • Removing Hard Dependencies: 테스트를 짜기 쉽게 만들기 위해 코드를 수리적으로 유연하게 바꾸는 수순
  • Test Code Refactoring: 테스트 코드 자체에 쌓인 악취 제거와 물리적 유지보수
• How to Learn:
  • 대규모 레거시 함수를 리팩터링하기 전, 주변에 '성벽(테스트)'을 촘촘히 쌓고 하나씩 헐어가며 구조를 바꾸는 실습
  • 기능이 추가되지 않았음에도 테스트 코드를 수정해야 할 때, 그 물리적 부채를 수치적으로 판별하는 통찰 연구
• Implement: 리팩터링 전후의 '코드 한 줄당 테스트 실행 횟수'를 산출하여 안전도를 평가하는 GuardRating

7. Terminology

8. References

Primary

• [P2] SWEBOK v4.0 - Software Construction / Construction Technologies (Test-first development) — Methodological standards.
• [P5] SFIA v9 - Software Engineering / Programming/software development — Discipline requirements.

Secondary

• [Test Driven Development: By Example] Kent Beck — The definitive TDD book.
• [Unit Testing Principles, Practices, and Patterns] Vladimir Khorikov — Deep dive into AAA and verification.

Industry

• [Gherkin Style Guide: Given-When-Then] — The conceptual origin of AAA.
• [ThoughtWorks: Test Automation Strategy] — Industry adoption patterns.

9. Final Checklist

Primary

• 'Refactor' 단계에서 기능의 물리적 추가/변경 없이 오직 '구조'만 개선했음을 수리적으로 확신할 수 있는 가? (P2)
• 'TDD'가 코드의 '결합도($Coupling$)'를 물리적으로 어떻게 낮추도록 강제하는지 논리적으로 설명 가능한가? (P2)

Secondary

• 'AAA 패턴' 중 'Arrange' 영역이 너무 길어질 때, 이를 '팩토리(Factory)'나 '빌더(Builder)'로 물리적으로 위임하는 전략을 제안할 수 있는 가?
• 상태 검증만으로 부족하여 Mock을 이용한 '행위 검증'을 섞어야 할 때의 물리적 트리거 발동 조건을 소통 가능한가?

Industry

• 실무 개발 환경에서 한 사이클(R-G-R)의 물리적 시간이 10분을 넘길 때, 발생하는 개발 흐름의 수리적 손실을 분석할 수 있는 가? (SFIA)
• Clean Test의 원칙인 'F.I.R.S.T' 중 'Self-validating(자가검증)'이 AAA 패턴과 어떻게 수리적으로 결합되는지 논증할 수 있는 가?