e2e 테스트를 위해 속도를 우선시하지 말고 보다 스마트한 테스트 일정을 고려하십시오.

Cypress 및 Playwright와 같은 종단 간(e2e) 테스트는 Jest와 같은 단위/통합 테스트에 비해 느린 것으로 간주됩니다.

그러나 이 게시물에서는 몇 가지 DevOps 관행이 DevOps 주기에서 이 느린 성능 문제를 피할 수 있고 개발자가 e2e 기반 품질 보증을 최대한 활용할 수 있다고 주장하고 싶습니다.

그런데 느린 성능이 문제로 간주되는 이유는 무엇입니까?

테스트 성능은 일반적으로 개발자가 가능한 한 빨리 완료되어야 하는 CI/CD 주기에 테스트를 포함하기를 원하기 때문에 중요한 것으로 간주됩니다.

하나의 웹 페이지에 대해 하나의 e2e 테스트를 실행하는 데 일반적으로 30초 이상이 걸립니다. 따라서 e2e 테스트가 10페이지 이상을 다루는 경우 5분 이상 소요됩니다.

공통 CI/CD 파이프라인

기능 분기에서 끌어오기 요청 만들기

애플리케이션 빌드/컴파일

테스트 실행

새 분기를 기본 분기에 병합

서버에 새 응용 프로그램 배포

위의 CI/CD 패턴의 인기로 인해 프런트 엔드 개발자는 2단계에서 e2e 테스트를 포함하는 데 어려움을 겪습니다. 그러나 테스트가 개발 및 배포 흐름과 밀접하게 연결되어 있음을 의미합니다.

문제

원격 저장소에 새로 푸시할 때마다 완전히 새로운 테스트가 실행됩니다. 컴퓨팅 리소스 낭비가 너무 많습니다.

새로운 개발/리팩터링/구성으로 인해 일부 테스트가 쉽게 중단됩니다. 그리고 우리는 다른 시간에 깨진 테스트를 수정하고 싶습니다.

특정 상황에서만 전체 테스트 실행

2단계에 정적 테스트(eslint/prettier) 및 단위 테스트(Jest)를 포함하지만 전체 e2e 테스트는 포함하지 않습니다.

물론 애플리케이션을 프로덕션 환경에 릴리스하기 전에 준비된 e2e 테스트를 실행해야 합니다. 그러나 Git 태그는 일반적으로 요즘 프로덕션 릴리스를 제어하기 위해 사용됩니다. 실제로 Github 작업은 tag based actions을 지원합니다. 따라서 CI/CD 단계와 프로덕션 릴리스 단계를 분리할 수 있습니다.

영향을 받는 부품에 대해서만 e2e 테스트 실행

기능 분기에서 git 명령으로 수정된 파일을 검색하고 원격 저장소에 푸시할 때만 이러한 파일에 대한 e2e 테스트를 실행할 수 있습니다.

예를 들어 개발자가 pageA.js, pageB.js 및 pageC.js를 수정한 경우 CI/CD 파이프라인은 pageA.jstest.js, pageB.jstest.js 및 pageC.jstest.js를 실행합니다.

git ls-files | -I % /bin/bash -c '<test-command> %test.js;'

또는 영향을 받는 페이지에 대해 수동으로 테스트를 실행하고 테스트 결과를 내부 규정의 일부로 풀 요청 설명에 업로드할 수 있습니다.

모든 테스트를 병렬로 실행

Cypress 및 Playwright와 같은 대부분의 e2e 자동화 도구는 병렬 테스트 실행을 지원합니다.

병렬 처리 메커니즘은 파일 기반이므로 각 테스트가 너무 길어서는 안 됩니다. 테스트 파일 길이가 200줄 이상인 경우 테스트 파일을 두 개로 분할하는 것이 좋습니다.