테스트 커버리지의 함정: Stryker와 Cosmic Ray를 활용한 Mutation Testing 소개

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have the article text, I’ll translate it into Korean while preserving the original formatting, markdown, and any code blocks or URLs.

개요

목표: 코드 커버리지 메트릭의 한계를 극복하고 변이 테스트를 도입하여 테스트 코드가 실제로 비즈니스 로직의 오류를 잡아내는지 검증합니다.

범위: 엔터프라이즈 오케스트레이터 프로젝트 (Ochestrator)의 핵심 모듈을 프론트엔드(TypeScript)와 백엔드(Python) 모두에서 적용합니다.

예상 결과: 단순 라인 커버리지를 넘어선 변이 점수를 확보함으로써 코드 안정성과 테스트 신뢰성을 향상시킵니다.

우리는 종종 높은 테스트 커버리지가 안전한 코드를 의미한다고 믿습니다. 그러나 다음 질문에 답하기는 어렵습니다:

“테스트를 누가 검증하나요?”

단순히 코드를 실행하고 적절한 어설션이 없는 테스트도 커버리지 메트릭에 기여합니다. 이 coverage trap을 해결하기 위해 우리는 변이 테스트를 도입했습니다.

Source: …

구현

1. TypeScript 환경 – Stryker Mutator

TypeScript 환경(프론트엔드 및 공통 유틸리티)에서는 Stryker 를 선택했습니다. Vitest와 잘 통합되며 설정도 간단합니다.

기술 스택: TypeScript, Vitest, Stryker Mutator

핵심 설정 (stryker.config.json)

{
  "testRunner": "vitest",
  "reporters": ["html", "clear-text", "progress"],
  "concurrency": 4,
  "incremental": true,
  "mutate": [
    "src/utils/**/*.ts",
    "src/services/**/*.ts"
  ]
}

변경된 파일에 대해서만 테스트를 실행하도록 incremental 옵션을 활성화했습니다.

2. Python 환경 – Cosmic Ray

백엔드에서는 Cosmic Ray 을 도입했습니다. Python의 동적 특성을 활용해 AST(추상 구문 트리)를 조작함으로써 강력한 변이 생성이 가능합니다.

기술 스택: Python, Pytest, Cosmic Ray, Docker

실행 아키텍처: 변이 테스트는 리소스를 많이 소모하므로 여러 Docker 워커에서 병렬로 실행합니다.

# Partial docker-compose.test.yaml
cosmic-worker-1:
  command: uv run cosmic-ray worker cosmic.sqlite

cosmic-runner:
  depends_on: [cosmic-worker-1, cosmic-worker-2]
  command: |
    uv run cosmic-ray init cosmic-ray.toml cosmic.sqlite
    uv run cosmic-ray exec cosmic-ray.toml cosmic.sqlite

디버깅 / 도전 과제

실제 사례: VideoSplitter.ts에서 살아남은 뮤턴트

VideoSplitter.ts는 비디오 분할을 담당합니다. 라인 커버리지는 95 % 이상이었지만, Stryker는 많은 살아남은 뮤턴트를 발견했습니다.

문제 진술

// Original code
if (availableMemory  {
  // Simulate situations where memory is exactly equal to or slightly less than requiredMemory
  // ... reinforced test code ...
});

결과

• 발견 및 제거된 12개의 생존 변이체가 핵심 유틸리티 모듈에 있습니다.
• 테스트 코드를 단순히 실행하는 수준에서 실제로 검증하는 수준으로 끌어올렸습니다.

핵심 지표

핵심 요점

• 커버리지는 시작에 불과합니다 – 라인 커버리지는 테스트되지 않은 것을 알려주지만, 테스트된 것의 품질은 알려주지 않습니다.
• 뮤테이션 테스트는 비용이 많이 들지만 그만한 가치가 있습니다 – 실행에 수십 분이 걸릴 수 있지만, 핵심 비즈니스 로직에 대한 보상은 막대합니다.
• 점진적 도입 – 확장하기 전에 성공 사례를 만들기 위해 핵심 인프라 코드(예: VideoSplitter)부터 시작하세요.

Verification Checklist

• Overview – 목표와 범위가 명확합니다.
• Implementation – 기술 스택과 코드 예제가 포함됩니다.
• Debugging – 최소 하나의 구체적인 문제와 그 해결책이 설명됩니다.
• Results – 수치 데이터와 성과 지표가 제공됩니다.
• Key Takeaways – 배운 교훈과 향후 계획이 정리됩니다.

길이 가이드라인

• 전체: 400–800줄 (현재 약 100줄 – 필요에 따라 확장 가능)