2nd/10_Wiki/Topics/Development/Testing Strategy.md

id, category, confidence_score, tags, last_reinforced

id	category	confidence_score	tags	last_reinforced
P-REINFORCE-AUTO-WIKI-DEV-008	10_Wiki/💡 Topics/Development	0.95	development testing-strategy testability tdd automated-testing quality-assurance p-reinforce	2026-05-01

Testing Strategy

📌 한 줄 통찰 (The Karpathy Summary)

"코드의 의도를 명세화(Documentation)하고, 변경에 대한 즉각적인 회귀(Regression) 방지망을 구축하여 지속적인 배포와 리팩토링을 가능하게 하는 품질의 초석."

📖 구조화된 지식 (Synthesized Content)

테스트 전략은 단순한 버그 탐지를 넘어 설계의 무결성과 개발 속도를 보장하는 핵심 활동입니다.

1. 테스트 가능성 (Testability):
   • 설계적 접근: 코드가 쉽게 테스트될 수 있도록 의존성을 주입(DI)받고, 인터페이스를 통해 외부 모듈을 격리(Mocking)합니다. 정적 메서드나 싱글톤의 남용은 테스트 가능성을 저해합니다.
   • 결정론적 테스트: 테스트는 환경이나 실행 순서에 영향을 받지 않고 항상 동일한 결과를 내야 합니다.
2. Test-Driven Development (TDD):
   • 실패하는 테스트를 먼저 작성(Red) -> 기능을 구현(Green) -> 코드를 개선(Refactor)하는 사이클을 통해 테스트가 코드의 설계를 주도하게 만듭니다.
3. 리뷰 단계에서의 테스트:
   • 테스트 코드 우선 리뷰: 테스트를 먼저 읽으면 해당 기능의 유즈케이스와 의도를 더 명확히 파악할 수 있습니다.
   • 병합 차단 원칙: 새로운 기능이나 버그 수정은 반드시 관련 테스트를 포함해야 하며, 테스트 부재는 머지를 차단하는 중대한 사유입니다.
4. 엣지 케이스 및 실패 경로:
   • 정상 동작뿐만 아니라 Null 입력, 빈 배열, 유효하지 않은 데이터 타입 등 다양한 실패 시나리오를 포괄적으로 검증합니다.

⚠️ 모순 및 업데이트 (Contradictions & RL Update)

• 커버리지의 함정: 100% 테스트 커버리지라는 수치에 매몰되면 의미 없는 테스트 작성에 시간을 낭비하게 됩니다. 수치보다 '중요한 비즈니스 로직이 충분히 보호되고 있는가'라는 질적 지표가 우선되어야 합니다.
• 유지보수 비용: 테스트 코드 역시 관리 대상인 부채입니다. 과도하게 복잡한 테스트 로직이나 불필요한 구현 세부 사항에 결합된 테스트는 리팩토링을 방해할 수 있으므로, 테스트 자체의 품질과 단순성도 유지해야 합니다.

🔗 지식 연결 (Graph)

• Automated Quality & Review: 테스트가 자동으로 실행되는 환경.
• Dependency Injection (DI): 테스트 가능성을 높이는 핵심 기술.
• CI-CD Pipeline: 테스트 결과에 따라 병합 여부를 결정하는 시스템.
• Refactoring: 테스트라는 안전망이 있을 때 비로소 가능해지는 활동.
• Mocking and Test Doubles: 외부 의존성 격리 기법.

---