refactor(topics): 멀티 에이전트용 지식 재편 — _Common(공통 기본기) + Domain_* 구조
에이전트 8종(대화형/프로그래머 C·S/디자이너/설계자/기획자/QA/PD/PM)에게 [공통 기본 능력 + 롤별 Specialty] 2층으로 지식을 주입하기 위한 재분류. 문서 내용·포맷은 무수정, 폴더 이동만 (6,372개 문서 수 보존 확인). - Topic_Programming → Domain_Programming (내부 구조 보존) - Topic_Graphic → Domain_Design - Topic_Business → Domain_Product - Topic_General → Domain_General - _Common 신설: Math(구 Topic_Math_Specialty), Reasoning(구 General/From_Thinking & Reasoning), Reasoning_Creativity(구 General/From_창의성), Communication(Poetic_Blog_Writing + From_writing) - 타 도메인의 From_* 폴더는 유지 (출처 표기일 뿐, 이미 도메인에 맞게 분류된 문서) - 빈 폴더 정리 (memory/procedures) - 에이전트→폴더 매핑은 workspace의 .astra/agent-knowledge-map.json (9개 에이전트) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,26 @@
|
||||
---
|
||||
category: DevOps_and_Security
|
||||
tags: [auto-wikified, technical-documentation, devops_and_security]
|
||||
title: Mocking Framework
|
||||
description: "모킹 프레임워크(Mocking Framework)는 단위 테스트 수행 시 실제 서비스나 외부 종속성을 가짜(Mock) 객체로 교체하여, 비즈니스 로직을 변경하지 않고도 독립적인 테스트를 가능하게 하는 도구이다 [1]."
|
||||
last_updated: 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]. 또한 구조적으로 결합도가 높은 경우, 의존성을 모킹하기 위해 `proxyquire`나 `rewire`와 같은 도구를 사용해야 하며 이를 위한 수동 설정 작업이 요구된다 [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*
|
||||
Reference in New Issue
Block a user