Cypress 병렬 테스팅 환경 구축기
첫 번째 목표, 개발 과정에서 E2E 테스트에 실패한 코드의 병합을 막자
오랜만에 작성하는 블로깅이네요. 속한 조직의 산업 특성상 실무 경험을 공유하기 힘든 점이 있어 주말마다 해왔던 취미 생활 중 하나인 블로깅을 한동안 진행하지 못했지만, 오늘은 다행히도(?) 실무에 아직 도입하지 않은 기술을 접하게 되어 Hello World 찍어본 경험을 공유하게 되었습니다. Cypress 병렬 테스팅에 관심 있는 분이 계신다면 유료 서비스 도입 전에 Sorry-Cypress 오픈소스 도구를 살펴보시는 것도 좋은 방향일 것 같다는 생각이 들었어요.
여담으로 그동안 저의 부족한 브런치 블로그를 봐주시고 응원해 주신 분들 덕분에 테스트 자동화 프레임워크인 WebdriverIO를 활용한 웹 모바일 API 테스트 자동화 강의를 준비 중에 있어요. Cypress도 좋은 도구이고 WebdriverIO와 비교했을 때 장점과 단점이 확실한 도구라서 Cypress 실무 경험치가 늘어나면 해당 강의도 준비해 보려 하니 많은 관심과 사랑.. 부탁드리고, 가까운 시일 내에 테스트 자동화를 위한 JavaScript 강의와 WebdriverIO 강의로 찾아뵙도록 하겠습니다. :)
테스트 자동화 운영 단계에서 발생하는 일반적인 문제는 무엇인가?
CI 파이프라인과 로컬 개발 환경에서 수백 개의 테스트를 실행하기 시작했을 때 크게 3가지 문제에 직면한다.
1. 순차 테스트 실행에 많은 시간 소요
2. CI 환경(Headless Browser)의 테스트 실패는 디버깅이 어려운 점
3. Flaky Tests로 인해 발생하는 리소스 낭비
현재 직면한 핵심 문제는 무엇인가?
순차 테스트 실행에 많은 시간 소요
유료 서비스를 사용하지 않으면 Cypress로 병렬화가 불가하여 테스트 실행 속도에 영향을 미쳐 개발팀 작업에 병목과 생산성 저하가 발생할 수 있다.
핵심 문제를 해결하는 방안은 무엇인가?
1. Cypress Cloud 도입
2. 오픈소스 도구 조사 후 도입
현재 고려하지 않아도 될 기술적인 사항은 무엇인가?
1. 녹화, 스크린샷, 호출 스택 등이 담긴 테스트 자동화 운영에 필요한 대시보드
2. 테스트 스위트 안정성과 효율 그리고 성능 개선에 필요한 통계 및 메트릭 수집과 집계
3. 병렬 테스트 실행 순서 최적화를 통한 전체 테스트 실행 시간 최적화
4. 다른 도구(Jira 등)와의 통합
5. 특정 스위트의 단일 테스트 실패 시 테스트 전체 중단
6. 테스트 실패율이 높은 자동화 스위트를 우선적으로 실행
7. CI 환경에서의 실행 취소
8. 불안정 테스트 분석에 대한 통계(불안정 테스트 수, 취약성, 사양 파일 수 등)
9. REST API를 통해 프로그래밍 방식으로 테스트 결과와 아티팩트 액세스 가능 여부
반드시 충족되어야 할 기술적인 사항은 무엇인가?
Basic Parallelization / Load Balancing
CI와 로컬 시스템에서 테스트를 자동으로 분할하는 기본 병렬화와 더불어 테스트 분할에 필요한 로드 밸런싱 가능 여부
Sorry-Cypress 도입 결정 및 구축
위와 같은 기준을 통해 Basic Parallelization / Load Balancing을 지원하는 오픈소스 도구인 Sorry-Cypress 도입을 결정하게 되었고 구축 과정은 다음과 같다.
Step1. cypress-cloud 설치
npm install cypress-cloud cypress
cypress 개발 환경에 cypress-cloud 설치
Step2. Sorry Cypress의 자체 호스팅 디렉터 서비스로 설정하기 위한 currents.config.js 구성
Step3. cypress.config.js 구성
Step4. sorry-cypress kit 구성
docker-compose.minio.yml 편집하여 각 services의 environment를 현재 개발 환경에 맞춰 수정
Sorry-Cypress 사용
Step1. 대시보드 접근 및 프로젝트 생성
Step2. 테스트 실행
동일한 --ci-build-id값을 사용하여 서로 다른 cypress 에이전트를 동일한 실행에 연결 가능
테스트 실행 결과 영상 및 실패 스크린샷 확인 가능
서로 다른 머신에서 진행된 테스트 결과를 대시보드에서 확인 가능
Sorry-Cypress Slack Integration
대시보드 프로젝트 세팅에서 Slack hook 설정
Hook Event 설정에 따라 필요한 알림 전송 가능
이로써 Sorry-Cypress 오픈소스 도구를 통해서 Cypress 유료 서비스를 도입하지 않고 자체적으로 병렬 테스트 환경 구축이 가능해졌다. 추후 자체 인프라에 배포하여 관리 필요한 상황이 생긴다면 AWS Cloud Formation 템플릿을 사용하여 AWS에 전체 sorry-cypress kit을 배포하여 운영할 계획이다. Cloud Formation 스택은 AWS Elastic Container Service(ECS)를 사용하여 sorry-cypress 서비스를 실행하며 구성에는 안전하고 편리한 액세스를 위한 네트워크 및 로드 밸런서가 포함된다.
Director URL - this is what you provide when configure cypress agent to use the alternative dashboard.
Dashboard URL - web dashboard access URL
API URL - GraphQL API access URL
S3 Bucket - for storing tests video recordings and screenshots
Cloudwatch log groups for debugging and troubleshooting
만약 Cypress 도입이 성공적으로 진행될 경우 다소 제한적인 기능만 존재하는 Sorry-Cypress 도구에서 https://currents.dev/# 와 같은 저비용 고효율의 Cypress Cloud 서비스를 활용하여 테스트 자동화의 유의미한 결과를 만들어가고자 한다.
무척이나 더웠던 주말 아침, 카페에 홀로 앉아 시원한 아이스아메리카노를 주문하고 노드 백엔드 학습을 이어서 진행하고자 맥북을 켜던 찰나에 조직 내에서의 역할과 필요성에 대해 사뭇 진지한 생각에 빠져들게 되었다. 직업인으로서의 정체성과 더불어 내가 지닌 역량과 학습 패턴 그리고 커리어 방향성에 어울리는 형태로 무엇을 어떻게 기여할 수 있을까에 대해 마지막이라는 심정으로 한번 더 고민해 보게 되었다. 테스트와 품질 보증이라는 주제를 세분화하여 어떤 부분을 어떻게 기여할 수 있을지와 가장 열정 있고 시간 가는 줄 모를 만큼 재밌게 일을 할 수 있을지에 대해 고민한 끝에 Test Automation Evangelist의 존재 이유에 적합한 새로운 목표가 생기게 되었다.
FE팀과의 본격적인 협업을 준비함과 더불어 개발팀과 SQA 간의 테스트 전체 계층에 대한 가교 역할을 진행하고자 무엇을 할 수 있을까 고민하던 끝에, 테스트 계층별로 지속 가능한 측정과 자동화로 얻을 수 있는 이점에 대한 결과물을 위해서 Integration과 E2E 테스트 계층 중 일부 테스트 커버리지는 WebdriverIO에서 Cypress로 마이그레이션을 시작하게 되었다. WebdriverIO와 Cypress는 동작 원리에 있어서 큰 차이가 있기에 Cypress가 효과적인 것들 그리고 WebdriverIO가 효과적인 것들을 기준으로 고민하기 시작했다.
결과적으로 Cypress 도입의 첫 번째 목표는 개발 과정에서 E2E 테스트에 실패한 코드의 병합을 막는 것, WebdriverIO로도 충분히 구현 가능한 프로세스였지만 FE분들께 보다 친숙한 환경과 사용성을 고려한다면 Cypress가 보다 효과적이었다. 다만 Cypress 아키텍처의 한계로 인해 사용자 관점에서의 테스트 자동화가 불가능한 커버리지에 한해서만 WebdriverIO로 유지하도록 목표를 세웠다.
WebdriverIO-병렬 테스트그러던 찰나 마주쳤던 첫 번째 목표의 허들, 바로 테스트 실행 속도의 문제였다. Cypress는 WebdriverIO와는 다른 아키텍처로 동작하기 때문에 병렬 테스트 환경을 일반적인 Selenium Webdriver 병렬 테스트 환경으로 구축할 수 없었다. 공식문서를 살펴보니 Cypress에서 제공하는 클라우드(유료)를 사용해야 병렬화가 가능했고 큰 고민에 빠졌다. 개발 과정에서 E2E 테스트에 실패한 코드의 병합을 막자라는 첫 번째 목표의 허들이 테스트 실행 속도인 이유는 브라우저 내부를 조작하는 Cypress가 아무리 빠른다고 한들, Page Object Model 구조와 더불어 Mock Data를 적절히 활용하여 많은 수의 E2E 테스트 커버리지를 Cypress로 구현할 계획이었기 때문에 이를 실제 브라우저에서 구동할 경우 개발팀 작업 속도에 큰 병목이 생기기 때문이다. 테스트 코드 검증으로 인해 개발팀 생산성에 영향을 미치는 상황을 피하기 위해선 Cypress에서 구동 가능한 병렬 테스팅 환경 구축이 필요했고 이를 Sorry-Cypress 라이브러리로 해결한 과정을 담게 되었다.
