Files

T

koriweb 5ba5a55c78 feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]

2026-05-08 19:52:07 +09:00

5.5 KiB

Raw Blame History

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit, tech_stack

title

테스트_전략_및_방법론

📌 한 줄 통찰 (The Karpathy Summary)

"테스트는 단순히 버그를 찾는 행위가 아니라, 코드의 변경에 대한 용기(Confidence)를 부여하고 설계의 품질을 강제하는 엔지니어링 규율이다."

📖 구조화된 지식 (Synthesized Content)

추출된 패턴:

자동화된 테스트를 통해 사소한 로직 결함을 기계가 선별하게 함으로써, 인간 리뷰어가 아키텍처와 비즈니스 맥락 등 고차원적 가치에 집중할 수 있는 '품질 게이트(Quality Gate)'를 구축하는 것이 핵심이다.

세부 내용:

테스트 계층 구조 (Testing Pyramid):
- 단위 테스트 (Unit Test): 개별 함수/클래스 독립 검증. 가장 빠르고 많아야 함.
- 통합 테스트 (Integration Test): 모듈 간 상호작용 및 데이터 흐름 검증.
- E2E 테스트 (End-to-End): 사용자 시나리오 기반 전체 시스템 흐름 검증.
주요 방법론:
- TDD (Test-Driven Development): [실패 테스트 작성 -> 구현 -> 리팩토링] 순환을 통해 테스트 용이성이 높은 설계 유도.
- BDD (Behaviour-Driven Development): 사용자 행위(Scenario) 중심 서술로 요구사항과 구현의 간극 해소.
자동화 및 CI/CD 통합:
- Pre-commit Hooks: 코드 제출 전 기초 테스트 및 린팅 강제.
- Branch Protection: 모든 테스트와 품질 검사를 통과해야만 병합 가능한 규칙 적용.
품질 지표와 한계:
- 커버리지 (Coverage): 80% 내외의 합리적 목표 설정 권장. 100% 강제는 무의미한 테스트 양산을 초래할 수 있음.
- 결정론적 테스트 (Deterministic): 무작위로 실패하는 'Flaky Test'를 제거하여 파이프라인 신뢰도 확보.

🤖 LLM 활용 힌트 (How to Use This Knowledge)

언제 이 지식을 쓰는가:

프로젝트 초기 단계에서 품질 관리 및 배포 자동화 파이프라인을 설계해야 할 때.
코드의 유지보수성이 떨어지고 변경 시마다 버그가 자주 발생하여 시스템적인 보완이 필요할 때.
신입 개발자나 협업 팀에게 우리 팀의 테스트 표준을 안내해야 할 때.

언제 이 지식을 쓰면 안 되는가:

일회성 스크립트나 실험적 프로토타이핑과 같이 코드 수명이 극히 짧은 경우.

이 지식을 적용할 때의 권장 절차:

단위 테스트 구축: 핵심 비즈니스 로직에 대해 작은 단위의 테스트부터 작성.
Mocking 활용: 데이터베이스나 외부 API 등 의존성을 격리하여 테스트 속도와 독립성 확보.
CI 연동: GitHub Actions 등을 통해 모든 PR에 대해 자동으로 테스트가 실행되도록 설정.
리뷰 문화: 테스트 코드 자체도 리뷰 대상에 포함하여 테스트의 적절성과 엣지 케이스 검증 여부 확인.

주의사항 또는 알려진 한계:

자동화 테스트는 패턴 기반 오류는 잘 찾지만, 비즈니스 맥락의 논리적 모순은 인간의 검토가 여전히 필요함.
테스트 코드가 프로덕션 코드보다 비대해지면 오히려 유지보수의 짐이 될 수 있으므로, '가치 있는 테스트'에 집중해야 함.

🧪 검증 상태 (Validation)

정보 상태: verified
출처 신뢰도: A
검토 이유: 해당 없음

🧬 중복 검사 (Duplicate Check)

기존 유사 문서: Testing Methodologies (테스트 방법론), Testing Strategy, Testing, Unit Testing, Integration-Testing-for-AI 등 다수
처리 방식: MERGE
처리 이유: 테스트의 이론, 계층, 자동화 전략을 담은 20여 개의 중복 문서를 통합하여 전사적 테스트 표준 가이드로 정립함.

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

과거 데이터와의 충돌: 없음
정책 변화: 단순 '버그 탐지'를 넘어 '리뷰어 에너지 보존'과 '설계 품질 강제'를 테스트의 핵심 가치로 격상함.

🔗 지식 연결 (Graph)

Parent: 10_Wiki/Topics
Related: Git_버전_관리_전략, SAST_정적_보안_진단_체계, CI_CD_파이프라인_자동화
Raw Source: 직접 입력

🕓 변경 이력 (Changelog)

날짜	변경 내용	처리 방식	신뢰도
2026-05-07	20개 이상의 테스트 관련 중복 문서를 통합 및 v3.0 규격 적용	MERGE	A

💻 코드 패턴 (Code Patterns)

패턴 1: (TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

(TODO)

선택 B를 써야 할 때:

(TODO)

기본값:

(TODO)

❌ 안티패턴 (Anti-Patterns)

[안티패턴]: (TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)

5.5 KiB Raw Blame History