토스 테스트 자동화 플랫폼 구축 영상 요약

개요

현재 직장에서 puppeteer기반 cypress 문법을 사용하는 e2e 테스트 프레임워크를 개발하고 있는데 알고리즘의 선택인지 우연인지는 모르겠지만 토스에서 비슷한 것을 만들고 발표한 영상이 눈에 들어오게 되었고 관심이 생겨 해당 영상을 꼼꼼히 보고 요약한 내용이다.

 

테스트 자동화 플랫폼을 만드는 목적이 다 같아서 그런건지 사람 생각이 다 거기서 거기라서 그런건지 cypress, playwright와 같은 타 테스트 프레임워크를 사용하지 않고 puppeteer 기반으로 테스트 프레임워크를 직접 만든다는 큰 차이를 제외하고는 많은 부분의 플랫폼 설계가 비슷하여 좀 신기했다. 

 

e2e 플랫폼을 만든다는 큰 목적을 가지고 구조와 흐름을 설계하게 되면 결국 누가 만들던간에 이런 느낌으로 완성이 되지 않을까 라는 생각이 든다.

 

유튜브 영상

https://www.youtube.com/watch?v=cGks5f2f0YE

 

 

요약

기존 테스트 자동화의 문제

1. 표준화 되지 않은 다양한 테스트 자동화 도구 사용
2. 표준회 되지 않은 자동화 테스트 코드 공유
3. 테스트 결과 가공의 어려움

→ 통합된 테스트 자동화 플랫폼의 제공으로 모든 문제 해결 가능

테스트 자동화 툴 Playwright

토스에서는 Playwright를 채택하여 사용. cypress와 굉장히 유사하며 선택한 이유는 아래와 같음

• 테스트 코드에 필요한 대부분의 함수 제공
• Visual Studio Code와 연동되는 개발 도구
• 리포트 생성 가능

Playwright는 테스트 실행, 결과 처리를 통합 제공해준다.

토스의 테스트 자동화 Platform에서 Playwright의 역할은 아래와 같다.

• 테스트 파일 실행 제어
• 테스트 파일의 실행 리포트 생성

→ 위 2개는 Playwright로 간단하게 해결 가능

• 실행 이력 조회

 

테스트 자동화 플랫폼 구성 요소

1. 어드민 서버: 테스트 관련 요청과 조회, 데이터 처리
2. 테스트 러너: Playwright 실행, 결과 전달
3. 배포 서버: JS파일 번들링, S3 업로드

 

 

테스트 러너의 역할

Playwright를 실행하여 테스트 코드를 제어하며 실행 결과를 가공하여 어드민 서버에 전달

테스트 코드 실행 과정

1. 어드민 서버: 테스트 실행 요청, 조회
2. SQS: 테스트 실행 요청량 제어
3. 테스트 러너: 테스트 진행, 실행 요청을 받은 테스트 러너는 S3를 통해 테스트 코드를 다운받은 뒤 실행
4. 테스트 러너: 테스트 결과를 어드민 서버로 전송

• S3: 테스트 코드 저장소

 

 

문제점

• 컴퓨팅 리소스 문제
  • 해결법 1 테스트 코드의 최대 실행 수 제어를 통해 문제 해결
  • SQS 배치를 통해 테스트 러너가 실행 가능한 수 만큼만 테스트를 실행하여 수평 확장 가능
  • 해결법 2
  • 테스트 결과를 청크 단위로 처리, 각 exepect 문에 대한 결과를 처리, 전송 이후 즉시 메모리에서 삭제하여 리소스 관리, Playwright의 Reporter 인터페이스를 구현하여 개발
• 테스트의 종류마다 필요한 리소스의 크기가 동적임 이로인해 병렬처리시에 리소스 부족으로 전체 테스트가 실패하는 경우가 발생
• 결과 파싱 문제
  • 해결법
  • Playwright Step 함수를 사용하여 코드를 스탭 함수로 감싸 해당 스탭의 타이틀 정보를 통해 결과를 분석 가능
• 테스트 실패 시 결과 JSON에 실패한 코드 정보가 남아있게 되지만 이를 보고 바로 어떤 테스트 케이스가 실패했는지 판단이 어려워서 테스트 코드를 보고 직접 비교하여 찾아야 하는 문제가 있음

배포 서버의 역할

• 테스트 파일의 번들링
• 테스트 파일의 S3 업로드

배포서버, CI/CD의 필요성

테스트 자동화 코드 작성도 코딩이다.

• 코드 품질 관리
• 자동 빌드
• 코드 통합
• 코드 리뷰

문제점

1. 실행할 테스트 파일 찾기→ 사람이 테스트 내용을 인지할 수 있는 방법이 필요함
2. 테스트 파일명은 테스트를 명확하게 표현할 수 없다.

해결 방법

원하는 테스트 파일을 조회하는 방법의 문제

테스트 케이스 ↔ 테스트 코드를 매핑 시킴

• 테스트 케이스는 테스트를 잘 나타내는 자연어, 검색 가능한 문서

 

위 이미지와 같이 테스트 케이스 ID, 테스트 명을 매핑시키는 테스트 케이스 테이블을 제공해주며 테스트 명을 통해 테스트 케이스 ID를 검색하여 테스트 코드를 찾는 방식을 채택

 

테스트 코드의 의존성 관리

테스트 코드 실행에 외부 의존성이 존재함

 

해결 방법

여러 의존성을 하나의 JS 파일로 생성하도록 번들링

테스트 코드 배포 과정

 

1. 테스트 코드 작성이후 git에 머지
2. 배포 서버에 이벤트가 발생하여 최신 코드 업데이트
3. 어드민에서 배포 요청 시 저장되어 있는 코드 기반으로 번들링하여 S3에 업로드
4. 이후 테스트 케이스, 테스트 명을 매핑하는 테이블 업데이트

 

테스트 실행 대시보드

대시보드를 만들 떄 아래 UI를 참고하여 만들면 참 좋을듯

테스트 조회, 결과 목록

 

 

테스트 코드 확인, 수정

 

테스트 결과 요약

 

이전 테스트 결과 요약 확인

 

 

테스트 결과 보고서 상세 확인

 

결론

영상을 본 뒤 어느정도 우리쪽에 적용하면 좋은 내용, 필요 없는 내용들에 대한 코멘트를 달아 관련 개발자들에게 따로 공유하였다. 구조가 비슷하다 해도 사용하는 사람과 목적이 어느정도는 다를 수 있기에 필요한 내용만 가져와 사용하기 위함이다. 해당 코멘트들은 본문에서는 제거하였으며 본문에는 순수하게 영상의 요약된 내용만 작성되어있다. 다만 처음 요약하는 과정에서 영상을 요약한다는 목적이 아니라 요약 이후 코멘트를 달아 공유하기 위한 목적이였기에 영상과 차이가 있을 수 있으니 참고하길바란다.

출처

https://toss.im/slash-24/sessions/15