팀은 95%의 코드 적용 범위를 자랑스럽게 보고한 다음 “커버된” 줄에 버그를 제공합니다. 이것은 모순이 아닙니다. Coverage는 하나의 좁은 질문에 답합니다. 테스트에서 이 코드를 실행했습니까? 결과를 확인했는지 여부는 완전히 다른 질문입니다.

우리는 Coverage.py 7.17 및 pytest 9.2와 함께 Python을 사용했습니다. 아래의 모든 숫자와 보고서는 우리가 직접 실행한 것입니다. 아이디어는 모든 언어에 적용됩니다.

코드 커버리지란 무엇입니까?

코드 적용 범위는 자동화된 테스트가 실행되는 동안 실행되는 코드의 비율입니다. 도구는 실행된 라인과 선택적으로 어떤 분기가 실행되었는지 기록한 다음 누락된 내용을 보고합니다.

역방향으로 가장 유용합니다. 특정 지역의 낮은 적용 범위는 테스트가 해당 지역을 실행하지 않는다는 것을 확실하게 알려줍니다. 높은 적용 범위는 훨씬 적은 것을 알려줍니다.

보장 유형

각 레벨은 그 위의 레벨보다 더 엄격합니다. 대부분의 팀은 회선 및 지점 범위를 추적합니다. 조건 적용 범위와 MC/DC는 툴링 지원이 전문화된 항공 및 자동차 표준에 나타납니다.

우리가 측정한 코드

def shipping_fee(total, is_member, express=False):
    if total < 0:
        raise ValueError("total cannot be negative")
    fee = 0 if total >= 1000 else 50
    if is_member:
        fee = max(fee - 25, 0)
    if express:
        fee += 100
    return fee

첫 번째 테스트 파일에는 두 가지 테스트가 있었습니다.

def test_regular_order():
    assert shipping_fee(500, False) == 50

def test_member_express():
    assert shipping_fee(500, True, express=True) == 125

분기 측정을 켠 상태에서 실행했습니다.

coverage run --branch -m pytest test_shipping.py
coverage report -m

보고서 읽기

Name          Stmts   Miss Branch BrPart  Cover   Missing
---------------------------------------------------------
shipping.py       9      1      6      1    87%   3

• Stmts 9, Miss 1: 실행 가능한 문 9개 중 하나는 실행되지 않았습니다.
• 분기 6, Br파트 1: 세 가지 if 결정은 여섯 가지 가능한 결과를 제공합니다. 단 하나의 결정은 한 방향으로만 진행되었습니다.
• 3번 누락: 3번째 줄인 raise ValueError는 실행되지 않았습니다. 마이너스 합계를 통과한 테스트가 없습니다.

수정은 오류 경로에 대한 테스트입니다. 또한 대량 주문에 대한 테스트도 추가했습니다.

def test_free_over_1000():
    assert shipping_fee(1000, False) == 0

def test_negative_total():
    with pytest.raises(ValueError):
        shipping_fee(-1, False)

두 파일 모두 보고서에 100%가 표시되었으며 누락된 줄이나 부분 분기가 없었습니다. 오류 경로는 고전적인 간격 범위 찾기이므로 등가 분할과 같은 기술로 설계된 유효하지 않은 입력에 대한 테스트가 오류 경로와 매우 잘 어울립니다.

보고서가 숨긴 것

첫 번째 보고서를 다시 살펴보세요. 3호선만 빠졌다고 하더군요. 그러나 처음 두 테스트에서는 모두 총 500개를 사용했기 때문에 1000개 이상 주문에 대한 무료 배송 규칙은 테스트되지 않았으며 보고서에서 이를 표시하지 않았습니다.

그 이유는 fee = 0 if total >= 1000 else 50이 한 줄에 있기 때문입니다. Coverage.py는 줄 사이의 분기를 측정하므로 단일 줄 내의 조건식은 하나의 실행된 문으로 계산됩니다. 해당 규칙에 >= 대신 >와 같은 버그가 있는 경우 첫 번째 모음은 힌트 없이 여전히 87%를 표시했을 것입니다. 경계 값 분석에 설명된 대로 경계 자체에 대한 테스트를 통해 이를 포착할 수 있습니다.

별도의 확인 없이 100% 보장

다음으로, 우리는 모든 경로를 호출하지만 아무것도 주장하지 않는 의도적으로 잘못된 테스트를 작성했습니다.

def test_runs_everything_but_checks_nothing():
    shipping_fee(500, True, express=True)
    shipping_fee(1000, False)
    shipping_fee(500, False)
    try:
        shipping_fee(-1, False)
    except ValueError:
        pass

shipping.py       9      0      6      0   100%

회선 및 지점 범위 100%에 도달했습니다. 이 함수는 어떤 숫자든 반환할 수 있으며 이 테스트는 여전히 통과할 것입니다. 이것이 적용 범위의 핵심 한계입니다. 검증이 아닌 실행을 측정합니다.

테스트가 실제로 버그를 잡는지 여부를 측정하려면 돌연변이 테스트를 사용하세요. Python용 mutmut, Java용 PIT 또는 JavaScript용 Stryker와 같은 도구는 >=를 >으로 바꾸는 등 코드를 약간 변경하고 테스트가 실패하는지 확인합니다. 우리의 비주장 테스트는 모든 돌연변이가 살아남도록 해줄 것입니다.

어떤 목표를 세워야 할까

보편적으로 정확한 숫자는 없습니다. 실용적인 지침:

• 100%를 쫓지 마세요. 마지막 몇 퍼센트는 종종 사소한 코드를 테스트하거나 라인만 터치하는 테스트를 작성하는 것을 의미합니다.
• 많은 팀이 전체적으로 약 70~85%를 목표로 하며 핵심 비즈니스 로직에 대한 기대치가 더 높습니다.
• 숫자가 아닌 추세를 살펴보십시오. 각 릴리스마다 감소하는 적용 범위는 경고 신호입니다.
• 이전 코드를 한꺼번에 강제 적용하는 대신 풀 요청에 새 코드 적용을 요구합니다.
• 생성된 코드와 같이 명확한 규칙을 사용하여 중요하지 않은 것은 제외합니다.

Goodhart의 법칙이 적용됩니다. 측정값이 목표가 되면 더 이상 좋은 측정값이 아닙니다. 하드 타겟은 no-assert 예시와 같은 테스트를 권장합니다.

언어별 도구

CI의 적용 범위

CI 파이프라인의 일부로 적용 범위를 실행하고 보고서를 게시하여 검토자가 어떤 새로운 라인이 테스트되지 않았는지 확인할 수 있습니다. Coverage.py를 사용하면 coverage report --fail-under=80가 임계값 미만의 빌드에 실패합니다. 임계값을 적당한 수준으로 유지하고 이를 새 코드에 대한 규칙과 결합하면 하나의 대규모 레거시 파일이 모든 변경 사항을 차단하지 않습니다.

적용 범위 너머: 더 나은 질문을 물어보세요

• 테스트가 위험하고 자주 변경되는 코드 부분을 다루나요?
• 행복한 경로뿐만 아니라 경계와 오류 경로도 테스트됩니까?
• 이 줄이 틀리면 테스트가 실패할까요?
• 테스트가 모든 변경 사항에 대해 실행될 수 있을 만큼 빠르고 안정적입니까?

이는 모든 테스트 전략에 속합니다. 적용 범위는 첫 번째 답변에만 도움이 됩니다.

코드 제외 및 HTML 보고서 읽기

디버그 도우미나 스크립트가 직접 시작될 때만 실행되는 블록과 같은 일부 코드는 직접 테스트할 가치가 없습니다. Coverage.py를 사용하면 주석이 있는 줄을 제외할 수 있습니다.

if __name__ == "__main__":  # pragma: no cover
    main()

예를 들어 pyproject.toml과 같이 구성에서 측정할 제외 항목과 소스 폴더를 설정할 수도 있습니다.

[tool.coverage.run]
branch = true
source = ["shop"]

[tool.coverage.report]
show_missing = true
exclude_also = ["if TYPE_CHECKING:"]

제외를 드물게 사용하고 코드처럼 검토하세요. 각각은 일부 라인을 절대 확인하지 않겠다는 결정입니다. 숫자를 늘리기 위해 테스트하기 어려운 오류 처리기를 제외하면 목적이 무산됩니다.

일상적인 작업에서는 HTML 보고서가 터미널 테이블보다 더 유용합니다. coverage html을 실행하고 htmlcov/index.html를 엽니다. 각 파일은 실행된 줄이 녹색으로, 누락된 줄이 빨간색으로, 부분 분기가 노란색으로 표시되므로 if이 다른 경로를 사용하지 않은 것을 한 눈에 알 수 있습니다. 많은 편집자들은 여백에 적용 범위를 표시할 수도 있는데, 이는 코드를 작성한 이후가 아니라 코드를 작성하는 동안 공백을 눈에 띄게 만듭니다.

리팩토링 전 적용 범위

Coverage는 리팩토링 전 안전 점검이기도 합니다. 모듈을 재구성하려는 경우 먼저 해당 보고서를 살펴보십시오. 빨간색 영역에는 동작 변경 시 경고하는 테스트가 없으므로 시작하기 전에 현재 동작을 캡처하는 특성화 테스트를 추가하세요. 이러한 방식을 사용하면 적용 범위가 더 이상 목표가 되지 않고 실용적인 계획 도구가 됩니다.

동일한 보고서는 버그가 프로덕션 환경으로 빠져나갈 때 도움이 됩니다. 버그가 발생한 줄을 찾아 테스트가 실행되었는지 확인하세요. 그렇지 않다면, 메울 가치가 있는 격차를 발견한 것입니다. 테스트가 실행되었다면 문제는 약한 주장이며, 이는 우리의 no-assert 예제에서 보여준 상황과 정확히 같습니다. 두 답변 모두 제품군을 개선하는 방법을 알려줍니다.

마무리

코드 적용 범위는 등급이 아니라 손전등입니다. 분기 적용 범위를 사용하여 테스트가 건드리지 않는 코드, 특히 오류 처리를 찾은 다음 실제 어설션을 작성하는 테스트를 작성하세요. 우리 실행의 한 가지 결과를 기억한다면 다음과 같이 하십시오. 아무것도 확인하지 않은 테스트에서 100% 적용 범위에 도달했습니다.

자주 묻는 질문

계속 학습하세요