Close

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

이 글에서는 코드 커버리지를 시작하고 적합한 도구를 찾고 계산하는 방법을 알아봅니다.

Sten Pittet 얼굴 사진
Sten Pittet

기고 작가


코드 커버리지란 소스의 얼마나 많은 부분이 테스트되는지 파악하는 데 도움이 되는 메트릭입니다. 테스트 스위트의 품질을 평가하는 데 도움이 되는 매우 유용한 메트릭으로 여기에서 프로젝트를 시작하는 방법을 살펴보겠습니다.

코드 커버리지 계산 방법


코드 커버리지 도구는 하나 이상의 기준을 사용하여 테스트 스위트를 실행하는 동안 코드가 어떻게 실행되었는지 확인합니다. 커버리지 보고서에 언급될 수 있는 일반적인 메트릭은 다음과 같습니다.

  • 함수 커버리지: 정의된 함수 중 호출된 함수의 수.
  • 구문 커버리지: 프로그램에서 실행된 구문의 수.
  • 브랜치 커버리지: 제어 구조의 브랜치(예: if 문) 중 실행된 브랜치의 수.
  • 조건 커버리지: true 및 false 값에 대해 테스트된 부울 하위 식의 수.
  • 줄 커버리지: 테스트된 소스 코드 줄의 수.

이러한 메트릭은 보통 실제로 테스트된 항목 수, 코드에서 찾은 항목, 커버리지 비율(테스트된 항목/발견된 항목)로 표시됩니다.

메트릭은 서로 관련되어 있지만 고유합니다. 아래의 간단한 스크립트에는 인수가 10의 배수인지 여부를 확인하는 Javascript 함수가 있습니다. 나중에 이 함수를 사용하여 100이 10의 배수인지 여부를 확인할 것입니다. 이는 함수 커버리지와 브랜치 커버리지의 차이점을 이해하는 데 도움이 됩니다.

솔루션 보기

Open DevOps로 소프트웨어를 구축 및 운영

관련 자료

DevOps를 위한 자동화된 테스트

coverage-tutorial.js

function isMultipleOf10(x) {   if (x % 10 == 0)     return true;   else    return false; }   console.log(isMultipleOf10(100));


커버리지 도구 istanbul을 사용하여 이 스크립트를 실행할 때 코드의 얼마나 많은 부분이 실행되는지 확인할 수 있습니다. 커버리지 도구를 실행하면 커버리지 메트릭이 표시된 커버리지 보고서를 받게 됩니다. 함수 커버리지는 100%지만 브랜치 커버리지는 50%에 불과하다는 것을 알 수 있습니다. 또한 istanbul 코드 커버리지 도구가 조건 커버리지 메트릭을 계산하지 않는다는 것도 확인할 수 있습니다.

명령줄에서 커버리지 보고서 받기

그 이유는 스크립트를 실행할 때 else 문이 실행되지 않았기 때문입니다. 100% 커버리지를 원하는 경우 if 문의 모든 브랜치가 사용되는지 확인하기 위해 한 줄(또다른 테스트)을 더 추가하면 됩니다.

coverage-tutorial.js

function isMultipleOf10(x) {   if (x % 10 == 0)     return true;   else     return false; }   console.log(isMultipleOf10(100)); console.log(isMultipleOf10(34)); // This will make our code execute the "return false;" statement.  


커버리지 도구를 두 번째로 실행하면 하단에 있는 두 개의 console.log() 문 덕분에 소스의 100%가 테스트된 것으로 표시됩니다.

모든 기준에서 100% 커버리지 달성

이 예시에서는 터미널에 결과를 로그했지만 테스트 스위트를 실행할 때도 같은 원칙이 적용됩니다. 코드 커버리지 도구는 테스트 스위트의 실행을 모니터링하고 테스트의 일부로 실행된 문, 브랜치, 함수, 줄의 양을 알려줍니다.

istanbul for Javascript에서는 각 경로의 커버리지에 대한 상세한 보고서를 볼 수 있습니다

코드 커버리지: 시작하기 위한 6가지 팁


1. 프로젝트에 적합한 도구 찾기

사용하는 언어에 따라 커버리지 보고서를 만드는 옵션이 여러 개 있을 수 있습니다. 많이 사용되는 몇 가지 도구는 아래와 같습니다.

도구 비교를 통해서도 결정을 내릴 수 있습니다. istanbul과 같은 일부 도구는 결과를 터미널에 바로 출력하는 반면 어떤 도구는 코드 중 커버리지가 부족한 부분을 살펴볼 수 있는 전체 HTML 보고서를 생성할 수 있습니다.

2. 커버리지는 몇 퍼센트를 목표로 해야 합니까?

코드 커버리지에 완벽한 해답이란 없으며 애플리케이션의 중요한 부분이 테스트되지 않거나 기존 테스트가 장애를 사전에 적절하게 포착할 만큼 강력하지 않은 경우 커버리지 비율을 높여도 여전히 문제가 될 수 있습니다. 그렇지만 목표로 삼기에 좋은 수준은 80%의 커버리지라고 일반적으로 받아들여지고 있습니다. 더 높은 커버리지에 도달하려고 하는 것은 비용이 많이 들 수 있으며, 그렇다고 해서 충분한 이점을 제공하는 것은 아닙니다.

커버리지 도구를 처음 실행하면 커버리지 비율이 상당히 낮다는 사실을 알게 될 것입니다. 테스트를 이제 막 시작하는 단계인 경우 이것은 정상적인 상황이며 바로 80%의 커버리지에 도달해야 한다는 압박감을 느끼지 않아도 됩니다. 그 이유는 커버리지 목표를 향해 서두르면 팀이 애플리케이션의 비즈니스 요구 사항에 기반한 테스트를 작성하는 대신 코드의 모든 줄에 대한 테스트를 작성하도록 만들 수 있기 때문입니다.

위의 예시를 설명하자면 100과 34가 10의 배수인지 테스트하여 100% 커버리지에 도달했습니다. 하지만 숫자 대신 문자로 함수를 호출하는 경우 true/false 결과가 나와야 합니까? 아니면 예외가 나와야 합니까? 팀이 코드의 줄만 보는 것이 아니라 사용자의 관점에서 테스트에 대해 생각할 시간을 주는 것이 중요합니다. 코드 커버리지는 소스에서 누락된 것이 있는지 여부를 알려주지 않습니다.

3. 먼저 단위 테스트에 집중

단위 테스트는 애플리케이션에서 사용하는 클래스와 구성 요소의 개별 메서드가 작동하는지 확인하는 것으로 구성됩니다. 일반적으로 구현 비용이 저렴하고 실행 속도가 빠르며 플랫폼의 기반이 견고하다는 전반적인 확신을 줍니다. 코드 커버리지를 빠르게 늘리는 간단한 방법은 먼저 단위 테스트를 추가하는 것입니다. 정의에 따르면 단위 테스트는 테스트 스위트가 모든 코드 줄에 도달하는지 확인하는 데 도움이 됩니다.

4. 커버리지 보고서를 사용하여 테스트에서 중대한 실수를 식별

머지않아 코드에 테스트가 너무 많아서 테스트 스위트를 실행하는 동안 애플리케이션의 어느 부분이 검사되는지 알 수 없게 될 것입니다. 빨간색 빌드가 표시되면 어떤 문제가 발생했는지 알 수 있지만 어떤 구성 요소가 테스트를 통과했는지는 파악하기 어려울 것입니다.

바로 이 부분에서 커버리지 보고서가 팀에 실행 가능한 안내를 제공할 수 있습니다. 대부분의 도구를 사용하면 커버리지 보고서를 자세히 살펴보고 테스트에서 다루지 않은 실제 항목을 확인한 다음 이를 사용하여 애플리케이션에서 아직 테스트가 필요한 중요한 부분을 파악할 수 있습니다.

SimpleCov for Ruby에서는 테스트되지 않은 메서드를 확인할 수 있습니다

5. 준비가 되면 코드 커버리지를 지속적 통합 흐름의 일부로 만들기

CI(지속적 통합) 워크플로를 구축한 후 커버리지 비율이 충분히 높지 않으면 테스트에 실패할 수 있습니다. 물론 앞서 말했듯이 실패 임계값을 너무 높게 설정하는 것은 합리적이지 않으며 커버리지가 90%인 경우 빌드가 많이 실패할 가능성이 높습니다. 80%의 커버리지를 목표로 한다면 CI 문화의 안전망 차원에서 실패 임계값을 70%로 설정해볼 수 있습니다.

다시 한 번 말하지만, 커버리지에 대한 잘못된 메시지를 보내지 않도록 주의하세요. 높은 커버리지에 도달하도록 팀에 압력을 가하면 잘못된 테스트 관행으로 이어질 수 있습니다.

6. 좋은 커버리지는 좋은 테스트와 다름

훌륭한 테스트 문화를 갖추는 것은 누군가가 애플리케이션을 제대로 사용할 때뿐만 아니라 누군가 버그를 발생시키려고 할 때도 애플리케이션이 어떻게 동작해야 하는지 팀이 이해하도록 만드는 것에서 시작됩니다. 코드 커버리지 도구는 다음 단계에서 주의를 기울여야 하는 부분을 파악하는 데 도움이 될 수 있지만 기존 테스트가 예상치 못한 동작에 대해 충분히 강력한지는 알려주지 않습니다.

높은 커버리지를 달성하는 것도 훌륭한 목표지만 개별 클래스가 손상되지 않도록 하고 시스템 무결성을 확인할 수 있는 강력한 테스트 스위트를 갖추는 것도 함께 이루어져야 합니다.

여기에서 다양한 유형의 소프트웨어 테스트에 대해 자세히 알아볼 수 있습니다. Atlassian의 Open DevOps는 사용자가 즐겨 사용하는 도구로 CD 기반 개발 파이프라인을 구축할 수 있는 개방형 도구 체인 플랫폼을 제공합니다. DevOps 테스트 자습서를 통해 Atlassian 도구 및 타사 도구가 워크플로에 테스트를 통합하는 방법을 알아보세요.

Sten Pittet
Sten Pittet

10년 동안 소프트웨어 사업 분야에 종사하며 개발에서 제품 관리에 이르기까지 다양한 역할을 맡았습니다. 지난 5년간 Atlassian에서 개발자 도구를 개발하는 일을 했고 이제 소프트웨어 구축과 관련한 글을 쓰고 있습니다. 직장 밖에서는 멋진 아기를 키우며 육아 기술을 연마하고 있습니다.


이 문서 공유

여러분께 도움을 드릴 자료를 추천합니다.

이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.

DevOps 일러스트레이션

DevOps 커뮤니티

DevOps 일러스트레이션

블로그 읽기

맵 일러스트레이션

무료로 사용해보기

DevOps 뉴스레터 신청

Thank you for signing up

다음 단계
지속적 배포