Files

T

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

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

6.4 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, inferred_by, tech_stack

title

Mocking and Stubbing (테스트 대역)

📌 한 줄 통찰 (The Karpathy Summary)

Mocking과 Stubbing은 프로덕션 환경에서 사용하는 실제 객체를 테스트 목적에 맞게 구현된 가짜 객체로 대체하는 '테스트 대역(Test Doubles)'의 두 가지 다른 종류이다 [1]. 이는 실제 클래스, 모듈, 함수를 대신하여 테스트 시작 시 미리 정의된 응답(canned responses)을 반환하도록 설정된다 [2]. 이를 통해 개발자는 데이터베이스나 네트워크 통신과 같이 속도가 느리거나 부수 효과가 큰 의존성을 분리하고, 복잡한 테스트 설정을 피해 코드를 통제된 환경에서 완벽히 격리하여 테스트할 수 있다 [2, 3].

📖 구조화된 지식 (Synthesized Content)

테스트 대역(Test Doubles)의 정의 및 역할: Mock과 Stub은 실제 컴포넌트와 동일한 서명(signature)을 가지면서도 테스트 시나리오에 맞춰 조작된 응답을 제공하는 가짜(fake) 버전의 컴포넌트이다 [2]. 단위 테스트뿐만 아니라 시스템의 특정 부분을 통제된 방식으로 시뮬레이션하기 위해 폭넓게 활용되며, 개발자는 Mockito나 Wiremock과 같은 서드파티 라이브러리를 통해 의존성을 손쉽게 Mocking하거나 외부 서비스를 Stubbing할 수 있다 [2, 4].
격리(Isolation)와 의존성 분리: 테스트를 작성할 때 외부 협력자(collaborator)로 인해 부수 효과가 발생하거나 설정이 복잡해지는 것을 막기 위해 테스트 대역을 사용한다 [3]. 특히 마이클 페더스(Michael Feathers)의 레거시 코드 리팩토링 전략에서는 테스트를 방해하는 무거운 외부 자원(DB, 네트워크 등)에 대한 직접적인 호출을 추상화하여, 테스트 시에 가짜 객체(Mock)를 주입할 수 있도록 '접점(Seams)'을 확보하는 것을 의존성 제거의 핵심으로 본다 [5, 6].
테스트의 단순화 및 예측 가능성 확보: Stubbing을 활용하면 테스트 데이터를 쉽게 설정할 수 있으며, 테스트가 훨씬 단순해지고 예측 가능해진다 [7]. 예를 들어, 서드파티 API(예: 날씨 정보 제공 서비스)와의 연동을 테스트할 때 실제 서버 대신 Fake 서버를 구축하여 테스트를 수행하면, 외부 서버의 할당량 제한이나 서버 점검 등의 가용성에 영향을 받지 않고 애플리케이션의 응답 파싱 능력을 독립적으로 검증할 수 있다 [8].
LLM을 활용한 테스트 생성에서의 활용: AI를 활용한 테스트 스위트(Test Suite) 구축 사례에서도 요청 가로채기(request interception)를 기반으로 한 API Mocking 계층을 중앙 집중화하여 중복을 줄이고 테스트 인프라의 안정성을 높인 바 있다 [9].

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

고립(Solitary) vs. 사교적(Sociable) 테스트의 트레이드오프: 모든 협력자를 Mock과 Stub으로 대체하여 완벽한 격리를 추구할 것인지(Solitary), 아니면 부수 효과가 큰 데이터베이스나 네트워크 호출 등 외곽 부분만 Stubbing하고 나머지 실제 협력자의 상호작용은 허용할 것인지(Sociable)에 대한 논쟁이 존재한다 [3]. 실제 객체와의 상호작용을 모두 Mocking하게 되면, 실제 협력자를 포함했을 때 얻을 수 있는 테스트의 통합적 신뢰성을 잃게 될 위험이 있다 [10].
가짜 객체(Test Double)의 신뢰성 한계 및 거짓 양성(False Positives): 외부 REST API 등을 Stubbing하여 가짜 서버(Fake server)를 만들 경우, 실제 외부 서비스의 API 스펙이 변경되더라도 가짜 서버를 바라보는 내부 테스트는 여전히 통과(Green)하는 취약점이 발생할 수 있다 [11]. 즉, 가짜 서버가 실제 서버의 동작을 완벽히 대변(faithful test double)하지 못할 위험이 있다 [11]. 이 제약을 극복하기 위해서는 가짜 서버와 실제 서버 모두에 대해 '계약 테스트(Contract Tests)'를 실행하여 Stub이 실제 스펙과 일치하는지 지속적으로 검증해야 한다 [11].
AI 생성 테스트의 한계: 거대 언어 모델(LLM)을 활용하여 자동 생성된 테스트의 경우, 일반적인 기법에 비해 문장 및 분기 커버리지는 우수하지만 여전히 Mocking 기능이 불충분하거나 테스트 자체가 깨지기 쉬운(brittleness) 문제가 발생할 수 있다 [12]. 이러한 한계는 프롬프팅 전략의 개선 등을 통해 보완해야 한다 [12].

Last updated: 2026-05-03

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

언제 이 지식을 쓰는가:

(TODO)

언제 쓰면 안 되는가:

(TODO)

🧪 검증 상태 (Validation)

정보 상태: needs_review
출처 신뢰도: A
검토 이유: (P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)

🧬 중복 검사 (Duplicate Check)

기존 유사 문서: (TODO: 인덱서 클러스터 리포트 참조)
처리 방식: UPDATE (자동 정규화)
처리 이유: Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

🔗 지식 연결 (Graph)

Parent: 10_Wiki/Topics
Related: (TODO: 최소 2개)
Opposite / Trade-off: (TODO)
Raw Source: 직접 입력

🕓 변경 이력 (Changelog)

날짜	변경 내용	처리 방식	신뢰도
2026-05-08	P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화)	UPDATE	A

💻 코드 패턴 (Code Patterns)

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

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

(TODO)

선택 B를 써야 할 때:

(TODO)

기본값:

(TODO)

❌ 안티패턴 (Anti-Patterns)

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

6.4 KiB Raw Blame History