단위 테스트 보고서
CI/CD 파이프라인에 테스트 작업을 포함하는 것이 매우 일반적입니다. 이 작업은 코드를 검증합니다. 테스트가 실패하면 파이프라인도 실패하고 사용자에게 알림이 전송됩니다. 병합 요청을 처리하는 사람은 작업 로그를 확인하여 테스트가 실패한 위치를 찾아 수정해야 합니다.
작업을 구성하여 단위 테스트 보고서를 사용할 수 있으며, GitLab은 병합 요청에 보고서를 표시하여 전체 로그를 확인하지 않고 실패 사항을 쉽고 빠르게 식별할 수 있도록 합니다. 단위 테스트 보고서는 현재 JUnit 보고서 형식의 테스트 보고서만을 지원합니다.
만약 병합 요청을 사용하지 않더라도 작업 로그를 검색하지 않고 단위 테스트 보고서 출력을 보려면 파이프라인 상세 보기에서 전체적인 단위 테스트 보고서를 사용할 수 있습니다.
다음의 워크플로우를 고려해 보세요:
- 기본 브랜치가 매우 견고하고 프로젝트가 GitLab CI/CD를 사용하며 파이프라인에 문제가 없음을 나타내고 있습니다.
- 팀원 중 누군가가 병합 요청을 제출하고 테스트가 실패하면 파이프라인에 알려지는 빨간 아이콘이 표시됩니다. 더 자세히 조사하려면 일반적으로 수천 줄을 포함하는 실패한 테스트의 원인을 파악하기 위해 작업 로그를 확인해야 합니다.
- 단위 테스트 보고서를 구성하면 즉시 GitLab이 보고서를 수집하고 병합 요청에 노출시킵니다. 더 이상 작업 로그를 검색할 필요가 없습니다.
- 개발 및 디버깅 워크플로우가 더 쉬워지고 더 빠르고 효율적으로 사용할 수 있습니다.
작동 방식
먼저, GitLab Runner가 JUnit 보고서 형식 XML 파일을 모두 아티팩트로 GitLab에 업로드합니다. 그런 다음 병합 요청을 방문하면 GitLab은 기본 브랜치와 헤드 브랜치의 JUnit 보고서 형식 XML 파일을 비교하기 시작합니다. 여기서:
- 기본 브랜치는 대상 브랜치(일반적으로 기본 브랜치)입니다.
- 헤드 브랜치는 소스 브랜치(각 병합 요청의 최신 파이프라인)입니다.
테스트 요약 패널은 실패한 테스트의 수, 오류가 발생한 수 및 수정된 테스트의 수를 보여줍니다. 기본 브랜치의 데이터가 없기 때문에 비교를 수행할 수 없는 경우, 패널은 소스 브랜치의 실패한 테스트 목록만 표시합니다.
다음은 결과 유형입니다:
- 새로 실패한 테스트: 기본 브랜치에서 통과했지만 헤드 브랜치에서 실패한 테스트 케이스입니다.
- 새로운 오류 발생: 기본 브랜치에서 통과했지만 헤드 브랜치에서 테스트 오류로 실패한 테스트 케이스입니다.
- 기존 오류: 기본 브랜치에서 실패했고 헤드 브랜치에서도 실패한 테스트 케이스입니다.
- 해결된 실패: 기본 브랜치에서 실패했지만 헤드 브랜치에서 통과한 테스트 케이스입니다.
실패한 테스트 보기
테스트 요약 패널의 각 항목은 테스트 이름과 결과 유형을 표시합니다. 테스트 이름을 선택하여 실행 시간과 오류 출력에 대한 세부 정보가 포함된 모달 창을 열 수 있습니다.
실패한 테스트 이름 복사
- GitLab 15.2에 입힘.
테스트 요약 패널에 실패한 테스트가 나열된 경우에는 실패한 테스트의 이름과 경로를 복사할 수 있습니다. 이름과 경로를 사용하여 확인을 위해 로컬에서 테스트를 찾아 실행할 수 있습니다.
모든 실패한 테스트의 이름을 복사하려면 테스트 요약 패널 상단에서 실패한 테스트 복사를 선택하세요. 실패한 테스트는 테스트가 공백으로 구분되는 문자열로 표시됩니다. 이 옵션은 JUnit 보고서가 실패한 테스트의 <file> 속성을 채우는 경우에만 사용할 수 있습니다.
단일 실패한 테스트의 이름을 복사하려면:
- 테스트 요약 패널을 확장하여 테스트 요약 세부정보 표시를 선택합니다().
- 확인하려는 테스트를 선택합니다.
- 로컬에서 다시 실행할 테스트 이름 복사를 선택합니다().
최근 실패 횟수
지난 14일 동안 프로젝트의 기본 브랜치에서 테스트가 실패한 경우, 해당 테스트에 대해 {default_branch}에서 {n} 번 실패와 같은 메시지가 표시됩니다.
이 계산에는 완료된 파이프라인에서 실패한 테스트가 포함되지만 차단된 파이프라인은 포함되지 않습니다. 이슈 431265에서는 계산에 차단된 파이프라인도 포함하는 것을 제안하고 있습니다.
설정 방법
병합 요청에서 단위 테스트 보고서를 활성화하려면 .gitlab-ci.yml에 artifacts:reports:junit를 추가하고 생성된 테스트 보고서의 경로를 지정해야 합니다. 보고서는 반드시 .xml 파일이어야 하며, 그렇지 않으면 GitLab은 오류 500을 반환합니다.
다음은 Ruby 예제입니다. test 단계에서 실행되는 작업이며, GitLab은 작업에서 단위 테스트 보고서를 수집합니다. 작업이 실행된 후 XML 보고서가 아티팩트로 저장되며, 그 결과가 병합 요청 위젯에 표시됩니다.
## https://github.com/sj26/rspec_junit_formatter를 사용하여 rspec에서 JUnit 보고서 형식 XML 파일 생성
ruby:
stage: test
script:
- bundle install
- bundle exec rspec --format progress --format RspecJunitFormatter --out rspec.xml
artifacts:
when: always
paths:
- rspec.xml
reports:
junit: rspec.xml
단위 테스트 보고서 출력 파일을 찾아볼 수 있도록 하려면 예제와 같이 artifacts:paths 키워드로 포함하십시오. 작업이 실패하더라도(예: 테스트가 통과되지 않는 경우) 보고서를 업로드하려면 artifacts:when:always 키워드를 사용하십시오.
동일한 이름과 클래스를 가진 여러 테스트를 JUnit 보고서 형식 XML 파일에 가질 수 없습니다.
GitLab 15.0 및 이전 버전에서는 parallel:matrix 작업에서의 테스트 보고서가 집계되어 일부 보고 정보가 표시되지 않을 수 있으나, GitLab 15.1 및 이후에는 이 버그가 수정되어 모든 보고 정보가 표시됩니다.
GitLab에서 단위 테스트 보고서 보기
JUnit 보고서 형식 XML 파일이 생성되고 파이프라인의 일부로 업로드되면 이러한 보고서를 파이프라인 세부 정보 페이지 내에서 볼 수 있습니다. 이 페이지의 Tests 탭에는 XML 파일에서 보고된 테스트 스위트 및 케이스의 목록이 표시됩니다.
알려진 모든 테스트 스위트를 볼 수 있으며 각각을 선택하여 해당 스위트를 구성하는 케이스를 포함한 자세한 내용을 볼 수 있습니다.
GitLab API를 통해 보고서를 검색할 수도 있습니다.
단위 테스트 보고서 구문 분석 오류
JUnit 보고서 XML을 구문 분석하는 과정에서 오류가 발생하면 해당 작업 이름 옆에 표시기가 표시됩니다. 아이콘 위에 마우스를 올리면 툴팁에 구문 분석기 오류가 표시됩니다. 그룹화된 작업에서 여러 구문 분석 오류가 발생하는 경우 GitLab은 해당 그룹에서 첫 번째 오류만 표시합니다.
테스트 케이스 구문 분석 제한에 대해서는 단위 테스트 보고서 당 최대 테스트 케이스를 참조하십시오.
GitLab은 JUnit 보고서의 매우 큰 노드를 구문 분석하지 않습니다. 이를 선택 사항으로 만드는 데 대한 이슈가 오픈되어 있습니다.
GitLab에서 JUnit 스크린샷 보기
스크린샷을 artifacts로 GitLab에 업로드할 수 있습니다. JUnit 보고서 형식 XML 파일에 attachment 태그가 포함되어 있으면 GitLab이 해당 첨부 파일을 구문 분석합니다. 스크린샷 artifacts를 업로드할 때:
-
attachment태그에 업로드한 스크린샷의 경로가$CI_PROJECT_DIR를 기준으로 상대 경로로 포함되어 있어야 합니다. 예를 들어:<testcase time="1.00" name="Test"> <system-out>[[ATTACHMENT|/path/to/some/file]]</system-out> </testcase> -
테스트 실패 시에도 여전히 스크린샷을 업로드하도록 하려면 스크린샷을 업로드하는 작업을
artifacts:when: always로 설정해야 합니다.
첨부 파일이 업로드된 후에는 파이프라인 테스트 보고서에 스크린샷 링크가 포함되어 있습니다. 예를 들면:
문제 해결
테스트 보고서가 비어 보이는 경우
단위 테스트 보고서는 GitLab에서 볼 때 보고서를 포함하는 artifact가 만료될 경우 비어 보일 수 있습니다. 보고서 artifact가 너무 빨리 만료되는 경우 보고서 artifact의 expire_in 값을 더 오래 설정해야 합니다.
대안으로 새로운 보고서를 생성하도록 새 파이프라인을 실행할 수도 있습니다.
도움말