Files
2nd/10_Wiki/Topic_Programming/Architecture/Mocking_Framework.md
T
Antigravity Agent 9148c358d0 docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를
Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류.

- 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로
  자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거,
  동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거.
- 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming,
  Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business,
  Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로,
  나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는
  title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백).
  원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지.
- 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서.
- 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는
  지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지.
- Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경.
- 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
2026-07-05 00:33:48 +09:00

3.6 KiB

category, tags, title, description, last_updated
category tags title description last_updated
DevOps_and_Security
auto-wikified
technical-documentation
devops_and_security
Mocking Framework 모킹 프레임워크(Mocking Framework)는 단위 테스트 수행 시 실제 서비스나 외부 종속성을 가짜(Mock) 객체로 교체하여, 비즈니스 로직을 변경하지 않고도 독립적인 테스트를 가능하게 하는 도구이다 [1]. 2026-05-04

Mocking Framework

📌 Brief Summary

모킹 프레임워크(Mocking Framework)는 단위 테스트 수행 시 실제 서비스나 외부 종속성을 가짜(Mock) 객체로 교체하여, 비즈니스 로직을 변경하지 않고도 독립적인 테스트를 가능하게 하는 도구이다 [1]. 의존성 주입(DI) 구조의 유무에 따라 모킹의 복잡도가 크게 좌우되며, 시스템의 테스트 용이성을 결정짓는 핵심 요소로 작용한다 [1, 2]. 소스에 언급된 대표적인 모킹 도구로는 Java 생태계의 Mockito, React 환경의 Mock Service Worker(MSW), Node.js 환경의 proxyquire, rewire 등이 있다 [1, 3, 4].

📖 Core Content

  • NestJS의 의존성 주입(DI) 기반 모킹 패턴: NestJS는 테스트를 1급 관심사로 취급하며, 의존성 주입 메커니즘을 통해 모킹을 매우 직관적으로 지원한다 [1]. 프레임워크가 제공하는 테스트 모듈을 사용하면 단 몇 줄의 코드만으로 모의(Mock) 종속성이 포함된 격리된 인스턴스를 쉽게 생성할 수 있다 [1, 5].
  • Express에서의 수동 모킹 패턴: Express는 자체적인 테스트 전략을 강제하지 않으므로, 종속성 모킹을 위해 Jest, Mocha, Supertest 등의 도구를 직접 구성해야 한다 [2]. 또한 구조적으로 결합도가 높은 경우, 의존성을 모킹하기 위해 proxyquirerewire와 같은 도구를 사용해야 하며 이를 위한 수동 설정 작업이 요구된다 [1, 2].
  • Java 및 Spring Boot의 모킹 (Mockito): 헥사고날 아키텍처나 레이어드 아키텍처를 채택하는 Java 및 Spring Boot 기반 환경에서는 Java 컴포넌트의 단위 테스트를 위해 Mockito 프레임워크가 필수적으로 활용된다 [4, 6]. Spring Boot는 Mockito를 사용한 단위 테스트부터 테스트 컨테이너를 활용한 통합 테스트까지 포괄적인 모킹 및 테스트 환경을 제공한다 [5].
  • 프론트엔드 환경의 모킹 (MSW): React 애플리케이션 테스트 패턴에서는 Vitest, React Testing Library 등과 함께 Mock Service Worker(MSW)를 활용하여 데이터 페칭이나 외부 API 통신을 모킹하는 방식이 실전에서 사용된다 [3].

⚖️ Trade-offs & Caveats

프레임워크가 의존성 주입(DI) 구조를 강제하는지 여부에 따라 모킹을 위한 테스트 환경 설정의 트레이드오프가 명확히 발생한다 [1, 2]. NestJS나 Spring Boot처럼 구조화되고 DI를 제공하는 프레임워크는 비즈니스 로직 수정 없이 모의 객체(Mock)를 원활하게 교체할 수 있어 모킹 및 단위 테스트가 매우 간단해진다는 강력한 이점이 있다 [1, 2]. 반면, Express와 같이 유연하고 뼈대를 강제하지 않는 프레임워크는 초기 개발의 자유도는 높지만, 종속성 모킹과 테스트 환경 설정을 위해 수동 작업이 많이 필요하다는 단점이 있다 [2]. 특히 수동으로 의존성을 모킹하거나 proxyquire 같은 외부 모킹 툴에 지나치게 의존하는 패턴은 자칫 테스트 코드를 지저분하게(hacky) 만들고 유지보수성을 저하시킬 수 있다는 제약 사항이 있다 [1].


Last updated: 2026-05-03