✅ 레거시 코드에서 TDD 적용하기 | 5편: 테스트 커버리지 분석과 CI 환경 자동화 전략

드디어 레거시 코드에 TDD 적용하기 시리즈의 마지막 편입니다.
이번 글에서는 테스트 커버리지 도구를 활용해 코드의 품질을 수치로 확인하는 방법과,
CI(Continuous Integration) 환경에서 테스트를 자동화하는 전략을 단계별로 설명합니다.

테스트는 “작성”보다 “유지와 실행”이 더 중요합니다.
자동화되지 않은 테스트는 결국 방치됩니다.

🧪 1. 테스트 커버리지란?

테스트 커버리지(Test Coverage)는 전체 코드 중에서 테스트가 실제로 실행된 코드의 비율을 뜻합니다.
이는 단순히 "얼마나 테스트했는가"를 수치로 보여주는 중요한 지표입니다.

📊 주요 커버리지 지표

지표 종류	설명
라인 커버리지	전체 코드 줄 수 중 테스트로 실행된 줄의 비율
브랜치 커버리지	조건문(if, switch)의 true/false 실행 비율
메서드 커버리지	전체 메서드 중 테스트로 호출된 메서드 비율

🛠️ 2. MSTest에서 커버리지 측정하기 (.NET Framework)

Visual Studio에서는 기본적으로 테스트 커버리지 측정 도구를 제공합니다.

✅ 설정 및 실행 순서

Visual Studio → Test > Analyze Code Coverage > All Tests 클릭
테스트 실행 후 Code Coverage Results 창에서 확인

📌 결과 예시

OrderService.cs – 88.3%
UserService.cs – 100%
EmailSender.cs – 0% (테스트 불가 영역)

Note: static 클래스는 테스트에서 제외될 가능성이 높기 때문에, 가능한 DI 방식으로 전환해야 합니다.

🧰 3. 외부 테스트 커버리지 도구

도구	특징
Coverlet	.NET Core/Framework 모두 지원, CI 통합 쉬움
OpenCover	.NET Framework에서 강력한 커버리지 분석
ReportGenerator	커버리지 리포트를 HTML로 시각화

📌 Coverlet + ReportGenerator 사용 예시 (.NET Core 기준)


dotnet test /p:CollectCoverage=true
dotnet tool install -g dotnet-reportgenerator-globaltool
reportgenerator -reports:coverage.cobertura.xml -targetdir:coverage-report

✅ HTML 리포트 생성 → 시각화된 커버리지 확인 가능

⚙️ 4. CI 환경에서 테스트 자동화하기

테스트 코드를 작성해도 개발자가 직접 실행하지 않으면 무용지물입니다.
CI 환경에서 커밋 또는 PR 발생 시 자동으로 테스트가 실행되도록 구성해야 합니다.

✅ GitHub Actions 예제


name: Run Tests

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: windows-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v3

    - name: Setup .NET
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: '6.0.x'

    - name: Restore dependencies
      run: dotnet restore

    - name: Build solution
      run: dotnet build --no-restore

    - name: Run tests with coverage
      run: dotnet test --collect:"Code Coverage"

✅ GitHub에 푸시만 해도 자동 테스트 실행
✅ 실패한 테스트는 PR 머지 차단
✅ 코드 커버리지도 자동 측정 가능

✅ Bitbucket Pipelines 예제


image: mcr.microsoft.com/dotnet/framework/sdk:4.8

pipelines:
  default:
    - step:
        name: Build and Test
        image: mcr.microsoft.com/dotnet/framework/sdk:4.8
        caches:
          - dotnetcore
        script:
          - nuget restore YourSolution.sln
          - msbuild YourSolution.sln /p:Configuration=Release
          - vstest.console.exe YourTestProject\bin\Release\YourTestProject.dll

📌 MSTest 커버리지 측정 확장


OpenCover.Console.exe -target:"vstest.console.exe" -targetargs:"YourTest.dll" -output:coverage.xml
reportgenerator -reports:coverage.xml -targetdir:coverage-report

📌 커버리지 리포트 아티팩트 저장


script:
  - mkdir artifacts
  - cp -R coverage-report/* artifacts/
artifacts:
  - artifacts/**

📌 5. 테스트 자동화 전략 정리

항목	전략
커버리지 확보	테스트 안 되는 static 의존성 → 인터페이스로 리팩토링
필수 케이스 우선	Mocking보다 실제 DB/API 테스트도 적절히 포함
통합 vs 단위 테스트	속도와 목적에 따라 분리 실행
CI 자동화	GitHub Actions, Bitbucket Pipelines, Azure DevOps 등 연동
테스트 유지 관리	테스트 코드도 리팩토링 대상

🎯 결론

테스트는 "작성"보다 "실행 환경 구축"이 더 중요합니다.
단위 테스트 → 통합 테스트 → 커버리지 분석 → 자동화 순으로 발전시켜야 합니다.
레거시 코드도 전략적 리팩토링을 통해 충분히 TDD 환경에 적응시킬 수 있습니다.
CI 도구(GitHub Actions, Bitbucket Pipelines 등)를 활용해 테스트 실행을 자동화하면, 개발 품질과 협업 효율이 대폭 향상됩니다.

🚀 시리즈 전체 요약

편	주제
1편	MSTest 환경 설정과 첫 테스트
2편	외부 API/DB Mocking 전략
3편	테스트용 DB 구성과 통합 테스트
4편	DI 적용과 테스트 구조화
5편	커버리지 분석과 CI 자동화 전략

bbongz 님의 블로그