대리 테스트 (Surrogate Testing): 변이 테스트 (Mutation Testing)와 테스트 더블 (Test Doubles)을 활용한 견고한 QA 파이프라인 구축

대리 테스트 (Surrogate Testing): 변이 테스트 (Mutation Testing)와 테스트 더블 (Test Doubles)을 활용한 견고한 QA 파이프라인 구축

현대의 소프트웨어 팀에서 버그를 조기에 발견하려면 단순히 단위 테스트 (Unit Tests)를 작성하는 것 이상의 노력이 필요합니다. 정교하게 설계된 테스트 더블 (Test Doubles)을 사용하고 변이 기반 평가 (Mutation-based evaluation)를 수행하는 대리 테스트 (Surrogate testing)는 개발 속도를 희생하지 않으면서 테스트 품질을 향상시킬 수 있는 실용적이고 접근 가능한 경로를 제공합니다. 이 튜토리얼에서는 대리 테스트 전략을 설계하고, 도구를 설정하며, 기존의 단위/통합 테스트 (Unit/Integration tests)를 보완하는 엔드 투 엔드 (End-to-end) QA 워크플로우를 구현하는 과정을 안내합니다.

설명: 테스트 스위트 (Test suite)를 보안 카메라 시스템이라고 생각해 보세요. 단위 테스트 (Unit tests)가 근접 동작 감지기라면, 대리 테스트 (Surrogate testing)는 지능적인 대역 (Test doubles)과 의도적인 섭동 (Perturbations)을 추가하여 순수 단위 테스트가 놓치는 사각지대를 드러내는 역할을 합니다.

학습 내용

• 테스트 더블 (Test doubles)과 변이 기반 체크 (Mutation-based checks)의 차이점
• 불안정성 (Flakiness) 없이 실제 협력자를 모방하는 테스트 더블 (Test doubles) 설계 방법
• 비용 효율적이고 실행 가능한 변이 테스트 (Mutation testing) 워크플로우
• 선택적 병렬 실행을 통해 CI에 대리 테스트 (Surrogate testing)를 통합하는 방법
• 데이터 픽스처 (Data fixtures), API 스텁 (API stubs), 외부 서비스 모의 객체 (External service mocks)를 위한 실용적인 패턴
• Node.js/TypeScript 프로젝트 및 Python 프로젝트에서의 예시 파이프라인

1. 핵심 개념 및 대리 테스트 (Surrogate testing)가 중요한 이유

• 테스트 더블 (Test doubles): 테스트에서 실제 협력자 (collaborators)를 대신하는 객체 또는 컴포넌트입니다. 여기에는 모의 객체 (mocks), 스텁 (stubs), 페이크 (fakes), 스파이 (spies)가 포함됩니다. 올바르게 사용하면 테스트의 불안정성 (flakiness)을 줄이고 테스트 대상 단위 (unit under test)를 격리할 수 있습니다.
• 변이 테스트 (Mutation testing): 도입된 결함을 테스트가 잡아내는지 확인하기 위해 코드베이스의 일부를 의도적으로 변이 (mutating)시키는 방법입니다. 변이가 발생했음에도 테스트가 실패하지 않는다면, 테스트 커버리지 (test coverage)에 공백이 있거나 회귀 (regressions)를 감지하지 못하는 영역이 있다는 것을 의미합니다.
• 대리 테스트 (Surrogate tests): 현실적이고 제어 가능한 대리물 (stand-ins)을 사용하여 통합 의미론 (integration semantics)을 실행하는 집중된 테스트 서브셋 (subset)입니다. 이는 컴포넌트가 현실적인 실패 모드 (failure modes) 및 타이밍 시나리오에서 어떻게 동작하는지 조사합니다.

2. 효과적인 테스트 더블 (Test doubles) 설계하기
   원칙 (Principles)

• 행동 충실도 (Behavioral fidelity): 더블은 내부 구현이 아니라, 테스트 대상 단위가 의존하는 관찰 가능한 행동을 재현해야 합니다.
• 안정성 (Stability): 비결정론적 (nondeterministic) 동작을 명시적으로 테스트하는 경우가 아니라면, 더블은 결정론적 (deterministic)이어야 하며 무작위성 (randomness)이 없어야 합니다.
• 실패 모드에 대한 개방성 (Openness to failure modes): 더블은 성공 경로와 실패 경로(타임아웃, 부분적 실패, 느린 응답)를 모두 시뮬레이션해야 합니다.

패턴 (Patterns)

• API 스텁 (API stubs): 상위 서비스 (upstream services)를 모방하는 정적 응답 또는 단순 핸들러입니다.
• 가짜 데이터 저장소 (Fake data stores): 테스트를 위해 실제 데이터베이스처럼 동작하는 인메모리 (in-memory) 저장소입니다.
• 스파이 기능이 있는 협력자 (Spy-enabled collaborators): 검증 (assertions)을 위해 상호작용(호출, 인자)을 기록하는 더블입니다.
• 시간 및 무작위성 제어 (Time and randomness control): 불안정한 타이밍 시나리오를 재현하기 위해 시계 (clocks)나 난수 생성기 (RNG) 시드를 주입합니다.

3. 변이 테스트 (Mutation testing): 가벼운 시작
   정의 (What it is)

• 변이 테스트는 코드의 작고 동등한 변형 (mutants, 변이체)을 생성하고, 테스트를 실행하여 실패 여부를 확인합니다. 강력한 테스트는 대부분의 변이체를 잡아내야 하며, 살아남은 변이체 (surviving mutants)는 공백이 있음을 나타냅니다.

실무적 접근 방식 (Practical approach)

• 신호(signal)가 높은 작은 모듈이나 서비스부터 시작하세요.
• 사용 중인 언어에 적합한 변이 테스트 도구 (mutation tool)를 사용하세요 (예:
  • JavaScript/TypeScript: Stryker
  • Python: MutPy 또는 py-mutator (또는 pitest에 상응하는 dy/dyn)
  • Go: go-mutesting과 유사한 도구들)
• 먼저 로컬에서 변이를 실행한 다음, 핵심 서비스(core services)에 대해 CI (지속적 통합)에서 실행하세요.

트레이드오프 (Trade-offs)

• 변이 테스트 (Mutation testing)는 비용이 많이 들 수 있습니다. 선택적 변이 (selective mutation, 파일의 일부 또는 영향력이 큰 로직)를 사용하고, CI가 매일 실행되거나 제한된 수의 변이체 (mutants)로 풀 리퀘스트 (pull requests) 시에만 실행되도록 구성하세요.

4. 엔드 투 엔드 (End-to-end) 대리 테스트 워크플로우
   1단계: 범위 정의 (Define the scope)

• 외부 시스템과의 통합이 빈번하게 발생하는 두세 개의 핵심 경로를 선택하세요 (예: 사용자 인증, 결제 처리 또는 주문 이행).
• 테스트의 불안정성 (flaky tests)을 자주 유발하는 협력자 (collaborators)를 식별하세요 (예: 제3자 API, 메시지 큐).

2단계: 테스트 더블 (test doubles) 라이브러리 구축

• 팀에서 확장할 수 있는 작고 재사용 가능한 테스트 더블 라이브러리를 만드세요.
• 도메인별로 정리하세요: apiClient, queueClient, cacheLayer, fileStorage.

3단계: 대리 테스트 (surrogate tests) 생성

• 테스트 더블을 통해 복잡한 상호작용을 수행하는 테스트를 작성하세요.
• 부분적 실패 (partial failures) 및 재시도 (retries)를 포함하여 성공 및 실패 모드를 모두 검증하세요.

4단계: 커버리지 피드백을 위한 변이 테스트 추가

• 구성된 모듈에 대해 변이 테스트를 실행하세요.
• 변이 점수 (mutation score)를 추적하고 변이되지 않은 코드 경로 (unmutated code paths)에 집중하세요.

5단계: CI 통합

• 모든 PR (pull request)에 대해 타겟팅된 방식으로 대리 테스트를 실행하세요 (예: PR 시 2~3개의 집중된 테스트 스위트 실행).
• 피드백 속도가 느려지는 것을 방지하기 위해 변이 테스트는 덜 빈번하게 실행하세요 (야간 또는 주말).
• 반복 실행 속도를 높이기 위해 아티팩트 캐시 (artifact caches)를 사용하세요.

6단계: 관찰 가능성 (Observability) 및 메트릭 (metrics)

• 대리 테스트의 커버리지를 측정하세요 (어떤 협력자/서비스가 실행되는지).
• 모듈별 및 테스트 더블 사용량별로 변이 점수를 추적하세요.
• 테스트의 불안정성 (flakiness) 비율과 근본 원인 해결 (root-cause fixes)을 모니터링하세요.

5. 구체적인 설정: Node.js/TypeScript 예시
   프로젝트 구조 (단순화됨)

• src/
  • services/
    • paymentService.ts
  • clients/
    • paymentGateway.ts
  • test/
    • surrogate/
      • mocks/
      • paymentService.surrogate.test.ts
  • doubles/
    • apiClient.ts
    • paymentGatewayMock.ts
• package.json: test, mutate, ci를 위한 스크립트

예시: 결제 흐름에 대한 대리 테스트 (surrogate test)

• paymentService.ts는 결제 게이트웨이 (paymentGateway, 외부 서비스)와 캐시 계층 (cache layer)을 사용합니다.
• 대리 테스트는 성공, 거절, 타임아웃 (timeout)을 시뮬레이션할 수 있는 모의 결제 게이트웨이 (mock payment gateway)를 사용합니다.

코드 스케치 (Code sketch)

• doubles/paymentGatewayMock.ts
  • 제어 가능한 동작 (성공, 실패, 타임아웃)을 가지며, 결과로 resolve되는 Promise를 반환하는 processPayment(amount, currency) 메서드를 포함한 PaymentGatewayMock 클래스를 내보냅니다 (exports).
• test/surrogate/paymentService.surrogate.test.ts
  • 모의 게이트웨이 (mock gateway)와 가짜 캐시 (fake cache)를 사용하여 PaymentService를 설정합니다.
  • 테스트 항목:
    • 성공적인 결제는 캐시에 영수증을 저장합니다.
    • 결제 거절 시 적절한 에러를 반환하며 캐시에 기록하지 않습니다.
    • 게이트웨이 타임아웃은 재시도 정책 (retry policy)을 트리거합니다.
  • 모의 메서드 (mock methods)에 대한 스파이 (spies)를 사용하여 검증합니다.

변이 테스트 (Mutation test) 설정 (Stryker)

• 설치: npx stryker run stryker.config.js
• stryker.config.js는 관련 파일, 변이 도구 (mutators), 리포터 (reporters), 그리고 임계값 (thresholds)을 선택합니다.
• 범위 제한: 실행 시간을 실용적인 수준으로 유지하기 위해 결제 도메인 (payment domain)만 변이시킵니다.

6. 구체적인 설정: Python 예시
   프로젝트 구조 (단순화됨)

• app/
  • payments/
    • gateway.py
    • service.py
• tests/
  • surrogate/
    • test_payment_service.py
  • doubles/
    • mock_gateway.py

예시: Python을 위한 대리 테스트

• tests/surrogate/test_payment_service.py
  • 제어된 응답을 가진 모의 게이트웨이 (Mock gateway)
  • 상호작용을 단언 (assert)하기 위해 pytest 및 pytest-mock 사용
  • 성공, 잔액 부족, 그리고 재시도를 포함한 게이트웨이 타임아웃에 대한 테스트

Python에서의 변이 테스트 (Mutation testing)

• 도구 (Tools): MutPy 또는 cosmic-ray
• 예시 (Example): cosmic-ray init, 적은 수의 변이체 (mutants)를 사용하여 결제 모듈 (payments module)에서 실행.

7. 대리 테스트 (Surrogate testing)를 효과적으로 만들기 위한 실무 팁

• 작게 시작하기: 의존도가 높은 단일 서비스에 대해 대리 테스트 (surrogate tests)를 먼저 추가하세요.
• 더블 (doubles)을 프로덕션 시맨틱 (production semantics)에 가깝게 유지하기: 프로덕션 API가 변경되면 더블 (doubles)도 즉시 이를 반영해야 합니다.
• 결정론적 더블 (deterministic doubles) 선호하기: 의도적으로 비결정론 (nondeterminism)을 테스트하는 경우가 아니라면 무작위성 (randomness)을 피하세요.
• 의존성 주입 (Dependency Injection, DI) 사용하기: 테스트에서 실제 협력자 (collaborators)를 더블 (doubles)로 교체하기 위해 의존성 주입 (DI)을 사용하세요.
• 각 대리 테스트 (surrogate test)의 의도된 동작을 문서화하기: 상호작용 (interactions)과 결과 (outcomes)에 대해 무엇을 단언 (assert)하는지 명시하세요.
• CI에서 병렬화 (parallelization) 사용하기: 실행 시간 (runtimes)을 합리적인 수준으로 유지하기 위해 CI에서 병렬화를 사용하세요.

8. 예시 지표 및 성공 지표

• 대리 테스트 커버리지 (Surrogate test coverage): 테스트 더블 (test doubles)에 의해 실행되는 핵심 경로 (critical paths)의 백분율.
• 대리 테스트 모듈의 변이 점수 (Mutation score): 시간이 지남에 따라 80% 이상을 목표로 합니다.
• 대리 테스트의 플래키성 (Flakiness rate): 결정론적 더블 (deterministic doubles)을 사용하여 거의 0에 가깝게 줄입니다.
• CI 피드백 시간 (CI feedback time): PR에 대해 대리 테스트 스위트 (surrogate suite)가 5~10분 이내에 실행되도록 합니다.

9. 흔한 함정 및 방지 방법

• 함정: 더블 (doubles)이 너무 현실적이 되어 로직 (logic)을 인코딩하기 시작함
  • 해결책: 더블 (doubles)을 명시적인 동작 계약 (behavior contracts)을 가진 인터페이스 (interfaces)로 유지하세요. 더블 (doubles)에 비즈니스 규칙 (business rules)을 구현하는 것을 피해야 합니다.
• 함정: 변이 테스트 (Mutation testing)가 너무 느림
  • 해결책: 선택적 변이 (selective mutation), 병렬 CI 워커 (parallel CI workers), 그리고 아티팩트 (artifacts) 캐싱을 사용하세요.
• 함정: 대리 테스트 (Surrogate tests)가 프로덕션 현실에서 벗어남 (drift)
  • 해결책: 더블 (doubles)에 대한 정기적인 검토를 예약하고 API 계약 (API contract) 변경 사항과 일치시키세요.

10. 빠른 시작 체크리스트 (Quick-start checklist)

• 대리 테스트 (Surrogate tests)로 커버할 2~3개의 핵심 통합 경로 (Integration paths) 식별
• 도메인에 맞는 재사용 가능한 더블 (Doubles) 라이브러리 구축
• 성공 및 실패 시나리오를 모두 포함하는 대리 테스트 작성
• 핵심 모듈을 위한 경량 변이 테스트 (Mutation test) 워크플로우 구성
• 명확한 리포팅 기능을 갖춘 CI에 대리 테스트 통합
• 지표 (Metrics)를 모니터링하고 더블 (Doubles) 및 변이 (Mutations)에 대해 반복 개선

원하신다면 귀하의 스택(Node/TS, Python 또는 다른 언어)에 맞춘 최소한의 스타터 저장소 (Starter repo)를 맞춤 제작해 드릴 수 있으며, 작은 변이 설정 (Mutation config)과 CI 힌트를 포함하여 즉시 실행 가능한 예제 파일들을 제공해 드릴 수 있습니다. 귀하의 주요 환경은 어떤 언어와 프레임워크이며, GitHub Actions를 선호하시나요, 아니면 다른 CI 시스템을 선호하시나요?

Rizwan Saleem | https://rizwansaleem.co