1. Test Double이란
소프트웨어 테스트에서 **Test Double**은 실제 의존 컴포넌트를 대체하는 객체를 총칭한다. Martin Fowler가 정리한 분류에 따르면 Test Double은 크게 다섯 가지로 나뉜다.
1.1 Dummy
테스트에서 파라미터를 채우기 위해 전달하지만 실제로 사용되지 않는 객체다. 메서드 시그니처를 만족시키기 위해서만 존재한다.
// Dummy 예시: 실제로 호출되지 않는 logger
public class DummyLogger implements Logger {
@Override
public void log(String message) {
// 아무것도 하지 않음
}
}
1.2 Stub
**Stub**은 미리 정해진 응답을 반환하는 Test Double이다. 호출에 대해 고정된 데이터를 돌려주며, **상태 검증(State Verification)** 에 사용된다.
// Stub 예시: 항상 고정된 사용자를 반환
public class StubUserRepository implements UserRepository {
@Override
public User findById(Long id) {
return new User(1L, "testuser", "test@example.com");
}
}
핵심 특성:
- 미리 프로그래밍된 응답만 반환
- 호출 횟수나 순서를 검증하지 않음
- 테스트 후 **결과 상태**를 확인하여 검증
1.3 Mock
**Mock**은 호출 자체를 검증하는 Test Double이다. 특정 메서드가 특정 인자로 호출되었는지, 몇 번 호출되었는지 등 **행위 검증(Behavior Verification)** 에 초점을 맞춘다.
// Mockito를 사용한 Mock 예시
@Test
void shouldSendWelcomeEmail() {
EmailService mockEmailService = mock(EmailService.class);
UserService userService = new UserService(mockEmailService);
userService.registerUser("test@example.com");
// 행위 검증: sendWelcomeEmail이 정확히 1번 호출되었는지 확인
verify(mockEmailService, times(1))
.sendWelcomeEmail("test@example.com");
}
핵심 특성:
- 기대하는 호출(expectation)을 미리 설정
- 호출 횟수, 순서, 인자를 검증
- 기대와 다르게 호출되면 테스트 실패
1.4 Fake
**Fake**는 실제로 동작하는 경량 구현체다. 프로덕션에서는 사용하지 않지만 테스트 목적에는 충분히 동작한다.
// Fake 예시: In-Memory 데이터베이스
public class FakeUserRepository implements UserRepository {
private final Map<Long, User> store = new HashMap<>();
private long sequence = 1L;
@Override
public User save(User user) {
user.setId(sequence++);
store.put(user.getId(), user);
return user;
}
@Override
public User findById(Long id) {
return store.get(id);
}
@Override
public List<User> findAll() {
return new ArrayList<>(store.values());
}
}
대표적인 Fake 예시:
- H2 같은 인메모리 데이터베이스
- 로컬 파일 시스템 기반 스토리지
- 인메모리 메시지 큐
1.5 Spy
**Spy**는 실제 객체를 감싸서 호출 기록을 남기는 Test Double이다. 실제 동작을 수행하면서 동시에 호출 정보를 기록한다.
// Mockito Spy 예시
@Test
void spyExample() {
List<String> realList = new ArrayList<>();
List<String> spyList = spy(realList);
spyList.add("hello"); // 실제로 요소가 추가됨
verify(spyList).add("hello"); // 호출 기록 확인
assertEquals(1, spyList.size()); // 실제 동작 확인
}
1.6 비교 요약 표
| 구분 | 동작 | 검증 방식 | 대표 사례 |
| ----- | ---------------------- | ----------- | --------------- |
| Dummy | 없음 (파라미터 채움용) | 없음 | 빈 구현체 |
| Stub | 고정 응답 반환 | 상태 검증 | 하드코딩된 응답 |
| Mock | 호출 기대 설정 | 행위 검증 | Mockito mock |
| Fake | 실제 경량 구현 | 상태 검증 | In-memory DB |
| Spy | 실제 동작 + 기록 | 행위 + 상태 | Mockito spy |
2. Mocking 서버가 필요한 이유
마이크로서비스 아키텍처에서 외부 API에 의존하는 서비스를 테스트할 때 다음과 같은 문제가 발생한다.
- **외부 서비스 불안정**: 외부 API가 다운되면 내 테스트도 실패
- **Rate Limit**: 외부 API의 호출 제한으로 테스트 반복 불가
- **비용**: 유료 API를 테스트마다 호출하면 비용 발생
- **속도**: 네트워크 지연으로 테스트 시간 증가
- **엣지 케이스 재현**: 특정 에러 응답, 타임아웃 등을 재현하기 어려움
- **개발 환경 독립성**: 외부 서비스 없이도 개발 가능해야 함
Mocking 서버는 이 모든 문제를 해결해 준다. 실제 외부 서비스와 동일한 인터페이스를 제공하면서 예측 가능한 응답을 반환한다.
┌─────────────┐ ┌──────────────┐ ┌──────────────┐
│ 테스트코드 │─────>│ 내 서비스 │─────>│ Mocking 서버 │
│ │ │ │ │ (WireMock등) │
└─────────────┘ └──────────────┘ └──────────────┘
│
미리 정의된 응답 반환
3. 주요 Mocking 서버 도구
3.1 WireMock
WireMock은 가장 강력하고 기능이 풍부한 오픈소스 Mock 서버다. Java 기반이지만 독립 실행형(Standalone)으로도 사용할 수 있다.
**주요 기능:**
- JSON 기반 Stub 매핑 파일
- 강력한 Request Matching (URL, 헤더, 바디, 쿼리 파라미터)
- Response Templating (Handlebars 기반)
- Record/Playback 모드 (실제 API 트래픽 녹화)
- Stateful Behavior (시나리오 기반 상태 전이)
- Fault Injection (지연, 연결 끊김 시뮬레이션)
- Docker 이미지 제공
**Docker로 WireMock 실행:**
docker run -d --name wiremock \
-p 8080:8080 \
-v $(pwd)/stubs:/home/wiremock \
wiremock/wiremock:latest \
--global-response-templating \
--verbose
**기본 Stub 매핑 파일 구조:**
`stubs/mappings/get-user.json`:
{
"request": {
"method": "GET",
"urlPathPattern": "/api/users/[0-9]+",
"headers": {
"Accept": {
"contains": "application/json"
}
}
},
"response": {
"status": 200,
"headers": {
"Content-Type": "application/json"
},
"jsonBody": {
"id": 1,
"name": "John Doe",
"email": "john@example.com"
}
}
}
**Request Matching 패턴:**
{
"request": {
"method": "POST",
"urlPath": "/api/orders",
"bodyPatterns": [
{
"matchesJsonPath": "$.items[?(@.quantity > 0)]"
},
{
"matchesJsonPath": {
"expression": "$.customerId",
"regex": "^[A-Z]{2}[0-9]{6}$"
}
}
],
"queryParameters": {
"status": {
"equalTo": "active"
}
}
},
"response": {
"status": 201,
"jsonBody": {
"orderId": "ORD-001",
"status": "created"
}
}
}
**Response Templating 예제:**
{
"request": {
"method": "GET",
"urlPathTemplate": "/api/users/{userId}"
},
"response": {
"status": 200,
"headers": {
"Content-Type": "application/json"
},
"jsonBody": {
"id": "{{request.pathSegments.[2]}}",
"requestedAt": "{{now}}",
"userAgent": "{{request.headers.User-Agent}}"
},
"transformers": ["response-template"]
}
}
**Stateful Behavior (시나리오):**
{
"mappings": [
{
"scenarioName": "OrderFlow",
"requiredScenarioState": "Started",
"newScenarioState": "OrderCreated",
"request": {
"method": "POST",
"urlPath": "/api/orders"
},
"response": {
"status": 201,
"jsonBody": { "status": "created" }
}
},
{
"scenarioName": "OrderFlow",
"requiredScenarioState": "OrderCreated",
"request": {
"method": "GET",
"urlPath": "/api/orders/1"
},
"response": {
"status": 200,
"jsonBody": { "status": "processing" }
}
}
]
}
**Record/Playback 모드:**
실제 API로 프록시하며 응답을 녹화
docker run -d --name wiremock \
-p 8080:8080 \
-v $(pwd)/stubs:/home/wiremock \
wiremock/wiremock:latest \
--proxy-all="https://api.example.com" \
--record-mappings
3.2 MockServer
MockServer는 Java 기반의 Mock 서버로 WireMock과 유사하지만 차별화된 기능을 제공한다.
**주요 특징:**
- 런타임 동적 Expectation 설정 (API 호출로 Stub 추가/수정)
- Forward Proxy 모드 지원
- 요청/응답 검증 API
- OpenAPI 스펙 기반 자동 Mock
**Docker 실행:**
docker run -d --name mockserver \
-p 1080:1080 \
mockserver/mockserver:latest
**Expectation 설정 (REST API):**
curl -X PUT "http://localhost:1080/mockserver/expectation" \
-H "Content-Type: application/json" \
-d '{
"httpRequest": {
"method": "GET",
"path": "/api/products",
"queryStringParameters": {
"category": ["electronics"]
}
},
"httpResponse": {
"statusCode": 200,
"headers": {
"Content-Type": ["application/json"]
},
"body": {
"type": "JSON",
"json": "[{\"id\": 1, \"name\": \"Laptop\", \"price\": 999.99}]"
}
},
"times": {
"unlimited": true
}
}'
**Java 클라이언트로 Expectation 설정:**
new MockServerClient("localhost", 1080)
.when(
request()
.withMethod("GET")
.withPath("/api/products")
.withQueryStringParameter("category", "electronics")
)
.respond(
response()
.withStatusCode(200)
.withHeader("Content-Type", "application/json")
.withBody("[{\"id\": 1, \"name\": \"Laptop\"}]")
);
3.3 json-server
json-server는 Node.js 기반의 경량 REST API 서버다. JSON 파일 하나만으로 즉시 REST API를 제공한다.
**설치 및 실행:**
npm install -g json-server
db.json 파일 생성
cat > db.json << 'JSONEOF'
{
"users": [
{ "id": 1, "name": "Alice", "email": "alice@example.com" },
{ "id": 2, "name": "Bob", "email": "bob@example.com" }
],
"posts": [
{ "id": 1, "title": "Hello World", "userId": 1 },
{ "id": 2, "title": "Testing Guide", "userId": 2 }
]
}
JSONEOF
서버 실행
json-server --watch db.json --port 3001
**자동 생성되는 엔드포인트:**
CRUD 자동 지원
GET /users # 전체 목록
GET /users/1 # 단일 조회
POST /users # 생성
PUT /users/1 # 전체 수정
PATCH /users/1 # 부분 수정
DELETE /users/1 # 삭제
쿼리 기능
GET /users?name=Alice # 필터링
GET /users?_sort=name&_order=asc # 정렬
GET /users?_page=1&_limit=10 # 페이지네이션
GET /posts?_expand=user # 관계 확장
**커스텀 라우트와 미들웨어:**
// server.js
const jsonServer = require('json-server')
const server = jsonServer.create()
const router = jsonServer.router('db.json')
const middlewares = jsonServer.defaults()
// 커스텀 미들웨어: 인증 헤더 검사
server.use((req, res, next) => {
if (req.headers.authorization === 'Bearer test-token') {
next()
} else {
res.status(401).json({ error: 'Unauthorized' })
}
})
server.use(middlewares)
// 커스텀 라우트
server.get('/api/health', (req, res) => {
res.json({ status: 'ok', timestamp: new Date().toISOString() })
})
server.use(router)
server.listen(3001, () => {
console.log('JSON Server is running on port 3001')
})
3.4 Prism (Stoplight)
Prism은 OpenAPI(Swagger) 스펙을 기반으로 자동으로 Mock 서버를 생성해 주는 도구다.
**설치 및 실행:**
npm install -g @stoplight/prism-cli
OpenAPI 스펙 파일로 Mock 서버 실행
prism mock openapi.yaml --port 4010
동적 응답 생성 모드
prism mock openapi.yaml --dynamic --port 4010
Validation Proxy 모드 (실제 서버 앞에서 요청/응답 검증)
prism proxy openapi.yaml https://api.example.com --port 4010
**OpenAPI 스펙 예시:**
openapi: 3.0.3
info:
title: User API
version: 1.0.0
paths:
/users:
get:
summary: List users
responses:
'200':
description: Success
content:
application/json:
schema:
type: array
items:
type: object
properties:
id:
type: integer
example: 1
name:
type: string
example: 'Alice'
email:
type: string
format: email
example: 'alice@example.com'
examples:
default:
value:
- id: 1
name: 'Alice'
email: 'alice@example.com'
'401':
description: Unauthorized
Prism은 스펙의 example 값을 우선 사용하고, `--dynamic` 모드에서는 스키마에 기반한 랜덤 데이터를 생성한다.
3.5 mitmproxy
mitmproxy는 HTTP/HTTPS 프록시로, 실제 트래픽을 가로채고 수정할 수 있다.
설치
pip install mitmproxy
인터셉트 프록시 실행
mitmproxy --listen-port 8888
스크립트 기반 응답 수정
mitmproxy -s modify_response.py
modify_response.py
from mitmproxy import http
def response(flow: http.HTTPFlow) -> None:
if "/api/users" in flow.request.pretty_url:
flow.response.status_code = 200
flow.response.set_text(json.dumps([
{"id": 1, "name": "Mocked User"}
]))
flow.response.headers["Content-Type"] = "application/json"
4. 도구 비교 표
| 기능 | WireMock | MockServer | json-server | Prism | mitmproxy |
| ------------------- | ---------------- | ----------------- | --------------- | -------------- | --------------- |
| 언어 | Java | Java | Node.js | Node.js | Python |
| 설정 방식 | JSON 파일/API | API | JSON 파일 | OpenAPI 스펙 | Python 스크립트 |
| Request Matching | 매우 강력 | 매우 강력 | 기본 | 스펙 기반 | 스크립트 기반 |
| Response Templating | Handlebars | Velocity/Mustache | 제한적 | 스펙 기반 | 자유로움 |
| Record/Playback | O | O | X | X | O |
| Stateful Behavior | O (시나리오) | O | O (CRUD) | X | O (스크립트) |
| OpenAPI 통합 | 플러그인 | O | X | 네이티브 | X |
| Docker 지원 | O | O | O | O | O |
| Fault Injection | O | O | X | X | O |
| HTTPS 지원 | O | O | X | O | O |
| 학습 곡선 | 중간 | 중간 | 매우 낮음 | 낮음 | 중간 |
| 적합한 용도 | 범용 통합 테스트 | 동적 API 테스트 | 프론트엔드 개발 | API-First 개발 | 디버깅/분석 |
5. WireMock 실전: Docker Compose 환경
5.1 프로젝트 구조
project/
docker-compose.yaml
wiremock/
mappings/
get-users.json
post-order.json
health-check.json
__files/
user-list.json
error-response.json
5.2 Docker Compose 설정
version: '3.8'
services:
wiremock:
image: wiremock/wiremock:latest
ports:
- '8080:8080'
volumes:
- ./wiremock/mappings:/home/wiremock/mappings
- ./wiremock/__files:/home/wiremock/__files
command:
- '--global-response-templating'
- '--verbose'
- '--disable-gzip'
healthcheck:
test: ['CMD', 'curl', '-f', 'http://localhost:8080/__admin/health']
interval: 10s
timeout: 5s
retries: 3
my-service:
build: .
environment:
- EXTERNAL_API_URL=http://wiremock:8080
depends_on:
wiremock:
condition: service_healthy
5.3 다양한 매핑 예제
**지연 응답 시뮬레이션:**
{
"request": {
"method": "GET",
"urlPath": "/api/slow-endpoint"
},
"response": {
"status": 200,
"fixedDelayMilliseconds": 3000,
"jsonBody": { "message": "delayed response" }
}
}
**랜덤 지연 (지터):**
{
"request": {
"method": "GET",
"urlPath": "/api/unstable"
},
"response": {
"status": 200,
"delayDistribution": {
"type": "lognormal",
"median": 1000,
"sigma": 0.25
},
"jsonBody": { "message": "response with jitter" }
}
}
**Fault Injection (연결 끊김):**
{
"request": {
"method": "GET",
"urlPath": "/api/fault"
},
"response": {
"fault": "CONNECTION_RESET_BY_PEER"
}
}
**우선순위 설정:**
{
"priority": 1,
"request": {
"method": "GET",
"urlPath": "/api/users/999"
},
"response": {
"status": 404,
"jsonBody": { "error": "User not found" }
}
}
6. API 계약 테스트(Contract Testing)
6.1 Pact
Pact는 소비자 주도 계약 테스트(Consumer-Driven Contract Testing)를 지원하는 프레임워크다.
┌──────────────┐ Pact 파일 생성 ┌──────────────┐
│ Consumer │ ──────────────────> │ Pact Broker │
│ (프론트엔드) │ │ │
└──────────────┘ └──────┬───────┘
│
Pact 파일 검증
│
┌──────▼───────┐
│ Provider │
│ (백엔드) │
└──────────────┘
**Consumer 테스트 (JavaScript):**
const { PactV3 } = require('@pact-foundation/pact')
const provider = new PactV3({
consumer: 'FrontendApp',
provider: 'UserService',
})
describe('User API', () => {
it('should return user by ID', async () => {
await provider
.given('a user with ID 1 exists')
.uponReceiving('a request for user 1')
.withRequest({
method: 'GET',
path: '/api/users/1',
headers: { Accept: 'application/json' },
})
.willRespondWith({
status: 200,
headers: { 'Content-Type': 'application/json' },
body: {
id: 1,
name: 'Alice',
email: 'alice@example.com',
},
})
await provider.executeTest(async (mockServer) => {
const response = await fetch(`${mockServer.url}/api/users/1`, {
headers: { Accept: 'application/json' },
})
const user = await response.json()
expect(user.name).toBe('Alice')
})
})
})
6.2 Spring Cloud Contract
Spring Cloud Contract는 Java/Spring 생태계에서 사용하는 계약 테스트 도구다.
**Contract 정의 (Groovy DSL):**
// contracts/shouldReturnUser.groovy
Contract.make {
description "should return user by ID"
request {
method GET()
url "/api/users/1"
headers {
accept(applicationJson())
}
}
response {
status OK()
headers {
contentType(applicationJson())
}
body([
id: 1,
name: "Alice",
email: "alice@example.com"
])
}
}
7. CI/CD 통합
7.1 Testcontainers + WireMock
@Testcontainers
@SpringBootTest
class ExternalApiIntegrationTest {
@Container
static WireMockContainer wiremock = new WireMockContainer(
"wiremock/wiremock:latest"
)
.withMappingFromResource("mappings/get-user.json");
@DynamicPropertySource
static void configureProperties(DynamicPropertyRegistry registry) {
registry.add("external.api.url", wiremock::getBaseUrl);
}
@Autowired
private UserClient userClient;
@Test
void shouldFetchUserFromExternalApi() {
User user = userClient.getUser(1L);
assertThat(user.getName()).isEqualTo("John Doe");
}
}
7.2 GitHub Actions에서 WireMock 사용
name: Integration Tests
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
services:
wiremock:
image: wiremock/wiremock:latest
ports:
- 8080:8080
volumes:
- ./wiremock/mappings:/home/wiremock/mappings
options: >-
--health-cmd "curl -f http://localhost:8080/__admin/health"
--health-interval 10s
--health-timeout 5s
--health-retries 3
steps:
- uses: actions/checkout@v4
- name: Run Integration Tests
run: |
./gradlew integrationTest
env:
EXTERNAL_API_URL: http://localhost:8080
7.3 Testcontainers + MockServer
@Testcontainers
class MockServerIntegrationTest {
@Container
static MockServerContainer mockServer = new MockServerContainer(
DockerImageName.parse("mockserver/mockserver:latest")
);
@BeforeEach
void setUp() {
new MockServerClient(
mockServer.getHost(),
mockServer.getServerPort()
)
.when(
request().withMethod("GET").withPath("/api/data")
)
.respond(
response()
.withStatusCode(200)
.withBody("{\"key\": \"value\"}")
);
}
}
8. Best Practices
8.1 Stub 파일 관리
- Stub 매핑 파일을 Git으로 버전 관리한다
- 환경별로 다른 매핑 세트를 준비한다
- 매핑 파일명에 의미 있는 이름을 사용한다 (예: `get-user-by-id.json`)
8.2 현실적인 Mock 데이터 만들기
// Faker.js로 현실적인 테스트 데이터 생성
const { faker } = require('@faker-js/faker')
function generateMockUsers(count) {
return Array.from({ length: count }, (_, i) => ({
id: i + 1,
name: faker.person.fullName(),
email: faker.internet.email(),
phone: faker.phone.number(),
address: faker.location.streetAddress(),
createdAt: faker.date.past().toISOString(),
}))
}
8.3 에러 시나리오 테스트
항상 다음 에러 상황에 대한 Stub을 준비해야 한다:
- **4xx 에러**: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests
- **5xx 에러**: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable
- **네트워크 에러**: Connection timeout, Connection reset, 빈 응답
- **느린 응답**: 타임아웃 임계값을 초과하는 지연
8.4 Contract Testing과 Mock 서버 조합
┌─────────────────────────────────────────────────┐
│ 테스트 전략 피라미드 │
│ │
│ ┌───────────────┐ │
│ │ E2E Tests │ ← 실제 환경 │
│ ┌┴───────────────┴┐ │
│ │ Contract Tests │ ← Pact/SCC │
│ ┌┴─────────────────┴┐ │
│ │ Integration Tests │ ← Mock Server │
│ ┌┴───────────────────┴┐ │
│ │ Unit Tests │ ← Mockito 등 │
│ └─────────────────────┘ │
└─────────────────────────────────────────────────┘
8.5 Mock 서버 선택 가이드라인
- **프론트엔드 개발**: json-server (빠른 시작, CRUD 자동 지원)
- **API-First 개발**: Prism (OpenAPI 스펙 기반 자동 Mock)
- **Java/Spring 통합 테스트**: WireMock (Testcontainers 통합, 강력한 매칭)
- **동적 시나리오 테스트**: MockServer (런타임 Expectation 변경)
- **트래픽 분석/디버깅**: mitmproxy (실제 트래픽 인터셉트)
- **계약 테스트**: Pact (Consumer-Driven) 또는 Spring Cloud Contract (Provider-Driven)
9. 고급 패턴: Service Virtualization
Mocking 서버를 넘어서 **Service Virtualization**은 실제 서비스의 복잡한 동작을 완전히 시뮬레이션하는 개념이다.
9.1 WireMock + Stateful Scenario로 워크플로 시뮬레이션
{
"mappings": [
{
"scenarioName": "PaymentFlow",
"requiredScenarioState": "Started",
"newScenarioState": "PaymentPending",
"request": { "method": "POST", "urlPath": "/api/payments" },
"response": {
"status": 201,
"jsonBody": { "paymentId": "PAY-001", "status": "pending" }
}
},
{
"scenarioName": "PaymentFlow",
"requiredScenarioState": "PaymentPending",
"newScenarioState": "PaymentCompleted",
"request": { "method": "POST", "urlPath": "/api/payments/PAY-001/confirm" },
"response": {
"status": 200,
"jsonBody": { "paymentId": "PAY-001", "status": "completed" }
}
},
{
"scenarioName": "PaymentFlow",
"requiredScenarioState": "PaymentCompleted",
"request": { "method": "GET", "urlPath": "/api/payments/PAY-001" },
"response": {
"status": 200,
"jsonBody": { "paymentId": "PAY-001", "status": "completed", "amount": 99.99 }
}
}
]
}
9.2 WireMock Admin API 활용
모든 매핑 조회
curl http://localhost:8080/__admin/mappings
요청 로그 조회
curl http://localhost:8080/__admin/requests
특정 패턴의 요청 카운트 확인
curl -X POST http://localhost:8080/__admin/requests/count \
-H "Content-Type: application/json" \
-d '{"method": "GET", "url": "/api/users"}'
시나리오 상태 초기화
curl -X POST http://localhost:8080/__admin/scenarios/reset
모든 매핑 초기화
curl -X POST http://localhost:8080/__admin/mappings/reset
10. 결론
Mocking 서버는 현대 소프트웨어 개발에서 필수적인 도구다. 올바른 도구를 선택하고 적절히 활용하면 개발 속도를 높이고, 테스트 신뢰성을 확보하며, CI/CD 파이프라인을 안정화할 수 있다.
핵심 정리:
- **Stub vs Mock**의 차이를 이해하고 상황에 맞게 사용한다
- **WireMock**은 가장 범용적이고 강력한 선택지다
- **json-server**는 프론트엔드 개발에 빠르게 적용할 수 있다
- **Prism**은 API-First 워크플로에 최적이다
- **Contract Testing**과 Mock 서버를 조합하면 마이크로서비스 테스트 전략이 완성된다
- CI/CD에서는 **Testcontainers**를 활용해 Mock 서버를 자동으로 관리한다
현재 단락 (1/695)
소프트웨어 테스트에서 **Test Double**은 실제 의존 컴포넌트를 대체하는 객체를 총칭한다. Martin Fowler가 정리한 분류에 따르면 Test Double은 크게 다...