쉽고 편리한 E2E 테스트 자동화를 꿈꾸며 (1)
쉽고 편리한 E2E 테스트 자동화를 꿈꾸며 (1) 관련
FEConf2024에서 발표한 <쉽고 편리한 E2E 테스트 자동화를 꿈꾸며>를 정리한 글입니다. 발표 내용을 2회로 나누어 발행합니다. 1회에서는 E2E 테스트, 그 테스트를 돕는 툴과 유지 보수 비용을 낮춰 효율적인 테스트 코드를 쌓아 올리는 방법에 대해 알아보겠습니다. 2회에서는 테스트 코드 재사용 및 모듈화와Playwright를 개선한 내용에 대해 알아봅니다. 본문에 삽입된 이미지의 출처는 모두 이 콘텐츠와 같은 제목의 발표 자료로, 따로 출처를 표기하지 않았습니다.
안녕하세요. ‘쉽고 편리한 E2E 테스트 자동화를 꿈꾸며’라는 제목의 발표를 진행할 백부석입니다. 저는 스스로를 실용주의 프로그래머라고 소개합니다. 대기업 SI와 홈쇼핑 커머스 등을 거치며, 반복 작업을 자동화하고 시간이 걸리는 작업을 최소화하기 위해 노력하고 있습니다. 현재 저는 고객들에게 마케팅 이메일을 제작하고 발송하는 서비스를 만드는 스티비에서 CTO로 일하고 있습니다. 스티비에서 2,800,000,000여 건의 이메일을 발송하며 얻은 이메일 호환성 최적화 경험을 소개하고, 이를 바탕으로 E2E에 대해 알아보겠습니다.
이번 글에서 다루는 내용들은 아래와 같습니다.
- E2E 테스트 자동화 도구의 발전
- E2E 테스트 자동화 및 효율성 향상
- Front 프로젝트 설정
반면, 아래의 내용들은 이번 글에서 전문적으로 다루지 않습니다.
- TDD
- 모바일 전문 E2E
- 테스트 CI / CD 파이프라인의 자동화
그럼 본론으로 들어가 보겠습니다.
E2E
E2E란
우리가 서비스를 운영할 때는 백엔드에서도 유닛 테스트를 하고 프론트엔드에서도 유닛 테스트를 하는 것이 좋습니다. 하지만 모든 단위에서 유닛 테스트가 잘 이뤄지지 않는 경우도 아주 많습니다. 그렇기 때문에 결국 E2E 테스트를 통해 사용자 관점에서의 테스트를 정립하고 검증해야 문제가 없다고 판단할 수 있습니다.
하지만 이러한 E2E 테스트가 어려운 이유는 아래 그림에서 알 수 있습니다. 유닛 테스트의 경우 프론트엔드나 백엔드 모두 비용도 상대적으로 적게 들고, 개발자가 스스로 빠르게 처리할 수 있습니다. 그러나 E2E 테스트는 통합 테스트이고, UI 테스트가 합쳐져 있기 때문에 테스트 코드를 작성하는 것부터 시간이 오래 걸리고, 테스트 속도도 상대적으로 느립니다.
그럼에도 신뢰가 높다는 장점 때문에, 어느 정도는 커버를 해야 한다고 판단했습니다.
E2E 테스트 과정
E2E 테스트를 하는 과정은 아래 그림처럼 진행됩니다. 테스트를 설계하고, 테스트를 작성하고 실행한 다음, 결과를 확인합니다. 설계 부분은 개발자의 영역이 아니기 때문에 이번 글에서 제가 소개할 내용은 없고, 테스트를 작성하는 부분에 대한 고민과 개선을 위한 노력에 대해 주로 소개하겠습니다.
마찬가지 작성 다음 영역인 테스트 실행 부분을 개선하기 위한 방법도 여러 가지가 있지만 이번 글에서는 중요하게 다루지 않습니다. 마지막으로 결과 보고를 통해 E2E 테스트 결과를 확인하는 부분이 있습니다. 어떤 회사에서는 테스트 결과를 동영상으로 확인하기도 하는데, 저의 경우 스크린샷을 통해 검증하는 것이 수월하게 작업할 수 있다고 생각해 그렇게 진행했습니다.
테스트 코드를 작성하다 보면 엔드 투 엔드를 모두 거쳐 가지만, 결국 프론트엔드 영역에서 시작할 수밖에 없습니다. 그렇기 때문에 이 부분을 자동화하여 테스트 코드를 생성하기 위한 고민을 했습니다. 여기에 디버깅 및 수정을 편하게 하고, 모듈화를 통해 재사용을 하고자 했습니다.
나의 E2E 이야기: 시작
제가 E2E에 관심을 가지고 개선을 시작했던 시기는 한 SI 프로젝트를 진행할 때였습니다. 당시에는 다양한 브라우저들의 렌더링 방식이 완전히 달랐고, 웹킷 자체가 없던 시기였기 때문에 HTML, CSS, 자바스크립트를 조금만 수정해도 브라우저의 렌더링 방식의 차이 때문에 각각의 브라우저에서 문제가 많이 생겼습니다. 이로 인해 검증할 때 시간을 많이 쓰게 됐고 불편한 점이 많았습니다. 그래서 이 부분을 개선해 보자라고 생각을 하게 됐습니다.
셀레늄(Selenium)
이를 개선하기 위해 처음에는 셀레늄(Selenium)이라는 웹 애플리케이션 테스트 및 자동화 툴을 사용했습니다. 셀레늄을 사용하면, 사용자가 검증하듯 녹화를 진행만 해도 테스트 코드를 자동으로 생성할 수 있습니다. 이렇게 생성된 코드를 DB에 저장하고 다시 보면서 재현하는 작업을 진행합니다.
셀레늄을 더 효율적으로 사용하기 위해 이미지를 통해 비교하는 아이디어를 생각했고, 마침 해커톤에 참여하는 기회가 생겨 생각만 하던 것들을 구현할 수 있었습니다.
당시 저는 셀레늄을 통해 테스트를 진행하는 단계 중간중간에 캡처를 할 수 있는 기능을 개발했습니다. 캡처를 비교하면서 A 브라우저와 B 브라우저가 어떤 차이가 있는지, 코드를 변경하면 어디서 문제가 발생하는지 알 수 있게 했습니다. 다만 위 이미지와 같이 몇 가지 한계도 있었습니다.
퍼펫티어(Puppeteer)
이렇게 셀레늄을 사용하던 와중에 퍼펫티어(Puppeteer)라는 툴이 출시가 됐습니다. 크롬 기반으로 사용하는 테스트 툴인데, 사용해 보니 셀레늄에 비해 아주 좋은 도구라는 생각이 들었습니다. 네트워크 제어 등에서 셀레늄보다 성능이 좋기 때문에 더 빠르게 테스트 코드를 생산할 수 있다고 기대했습니다.
그러나 퍼펫티어에도 큰 문제점이 하나 있었습니다. 바로 내부적으로 코드 생성을 지원하지 않는 것입니다. 그렇기 때문에 테스트 코드를 자동으로 생성하는 부분이 어려웠습니다. 이 부분을 개선하기 위해 코드 생성을 자동으로 해주는 익스텐션을 직접 만들어 보기도 했는데, 부족한 점이 많아서 다른 개발자가 만든 코드 생성 라이브러리를 사용했습니다.
그러나 테스트 코드를 작성하다 보면, 특정 단계에서 실패할 때 처음으로 돌아와 다시 진행하기 때문에 시간이 굉장히 오래 걸립니다. 아래 그림을 예로 들면, 로그인을 하고 장바구니에 물건을 담고, 구매하기를 하던 중 구매하기 단계에서 실패를 하면 처음부터 로그인을 하고 이후 과정을 다시 반복하는 식입니다.
이 부분을 개선하기 위해 브라우저의 세션 스토리지나 로컬 스토리지에 테스트 진행 상황을 자동으로 저장하고, 이를 브라우저를 실행할 때 로드해서 특정 체크포인트부터 다시 실행할 수 있도록 기능을 추가했습니다. 이렇게 다양한 노력을 들여 개선을 했는데도, 퍼펫티어는 부족한 부분이 많았기 때문에 동료 개발자들에게 추천하지는 않는 툴이었습니다.
셀레늄과 퍼펫티어의 한계
결국 테스트 코드 자동화를 위해서는 지원되어야 하는 부분에 셀레늄과 퍼펫티어는 어느 정도 한계가 있었습니다. 특히 Selector가 정교하지 못한 부분이 아쉬웠습니다.요즘 많이 사용하는 리액트나 뷰는 클래스 명을 동적으로 생성하기 때문에 CSS와 xpath를Selector로 사용하는 셀레늄과 퍼펫티어는 적합하지 않았습니다.
Playwright
그러다 이러한 단점들을 대부분 보완한 Playwright라는 툴이 나왔습니다. 퍼펫티어를 개발했던 분들이 MS로 옮겨가서 퍼펫티어 2.0 버전으로 만든 것이 Playwright라고 생각하면 될 것 같습니다. 개발자들에게 만들었던 걸 다시 만들라고 하면 좀 더 잘할 수 있듯이, Playwright도 더욱 많은 개선이 있었을 거라고 기대하면서 사용해 보기로 했습니다.
Playwright는 여러 장점이 있습니다. 다양한 브라우저를 지원하고, 테스트를 병렬로 실행하기 때문에 테스트 시간도 상당히 단축시킬 수 있습니다. 또한, 다양한 언어 지원과 강력한 네트워크 제어 기능을 통해 네트워크 요청을 인터셉트하고 수정할 수 있다는 특징이 있습니다.
이처럼 여러 특징 중에서도 제가 가장 중요하게 생각하는 특징은 바로 자동 코드 생성을 지원한다는 것입니다.
또, 앞서 말한 것처럼 녹화를 하기 위해 DOM을 선택하고, DOM을 재활용하는 셀렉터가 CSS나 xpath가 아닌 더 좋은 성능을 가진 것들로 지원하는 점도 좋았습니다. 그 외 스크린샷을 자동으로 찍는 기능, 브라우저 스토리지에 데이터를 저장하는 기능 등을 기본적으로 제공합니다.
이제 Playwright의 기본 기능을 조금 더 자세히 살펴보겠습니다.
먼저 VScode에 playwright를 설치하고, 녹화 버튼을 누르면 VScode에 코드가 자동으로 생성됩니다. 퍼펫티어에서도 지원하는 기능이지만, 녹화한 것을 플레이한다고 해서 완벽하게 동작하는 것은 쉬운 일은 아닙니다. 그렇기 때문에 이 기능은 매우 만족스러웠습니다.
E2E 예제
E2E 테스트 환경
이제 본격적인 예제 소개입니다. 많은 서비스에 존재하는 회원 가입이나 로그인을 포함해서, 제가 속한 스티비에서 자주 반복되는 작업인 주소록 생성, 이메일 생성, 이메일 발송, 이메일 수신을 예시로 E2E 테스트가 어떻게 진행되는지 알아보겠습니다.
E2E 테스를 진행하기 전에 먼저 선택해야 할 것이 있습니다. 일반적으로 테스트 환경을 만들어서 실행할 때는, 일시적인 환경을 생성해 테스트하는 방법과 지속 가능한 환경을 생성해 테스트하는 방법, 이렇게 두 가지 선택지가 있습니다.
여기서 일시적인 환경이란 테스트 코드를 만들고, 이 코드를 잘 동작시키기 위해 DB와 서버들을 도커로 실행해 확인하는 방법입니다. 이 방법은 테스트 케이스가 실패할 확률이 아주 낮습니다. 하지만 매번 일시적인 환경을 만드는 것은 실제 환경에 적용하기는 어렵다고 생각합니다.
저는 두 번째 방법인 운영 가능한 환경, 즉, 어떤 회사의 테스트 환경이나 검증 환경이라도 바로 실행시켜 확인할 수 있는 방법을 만들어보고자 했습니다. 이 방법을 사용하면 한 달 전, 1년 전에 회원 가입한 사람과 같은 기존 데이터에도 테스트를 실행하고 녹화하여 확인할 수 있습니다. 외부 인터페이스를 통해 계속 운영되고 있는 환경이라도 주기적으로 테스트 코드를 실행시켜서 문제가 없는지 바로 확인할 수 있습니다.
테스트 코드 작성
테스트 코드를 작성하면 유지 보수 비용이 굉장히 많이 들어간다는 것을 여러분도 알고 있을 거라 생각합니다. 그래서 E2E 테스트를 작성할 때, 유지 보수 비용이 많이 들어가는 부분을 최소화하고자 했습니다. 추가적으로 데이터를 조작하거나 테스트 코드를 위한 추가적인 API 개발은 최소한으로 줄여, 테스트 코드 수정이 생겼을 때도 추가적인 유지 보수 비용이 들지 않게 해야 합니다.
유지 보수 비용을 낮추는 방향으로 테스트 코드를 작성하지 않으면 결국 테스트 코드가 관리가 되지 않고, 테스트 코드를 작성하지 않는 원점으로 돌아가기 쉽습니다.
인증 서비스의 테스트 코드
E2E 테스트를 위해 만든 다양한 인증 서비스를 예시로 더 자세하게 알아보겠습니다. E2E 테스트를 진행하다 보면 인증 단계를 몇 차례 만나게 됩니다. Gmail 로그인, 다음, 네이버 로그인 등을 예로 들 수 있는데, 이런 인증 단계는 테스트 봇으로 접근하면 통과하지 못하게 막혀있습니다. 이런 인증 단계를 통과하기 위해 앞서 설명한 것처럼 추가적인 API 개발을 하지 않으면서, Websocket 기반 실제 이메일 인증을 진행하는 이메일 서비스를 만들었습니다.
다음으로 만나게 되는 인증은 바로 리캡챠 인증입니다. 퍼펫티어에서 지원하는 리캡챠 인증 라이브러리가 있긴 하지만 불안정하기 때문에 외부 서비스를 사용했습니다. 이 서비스를 실행하면 1분 정도 시간 동안 브라우저에서 무엇인가 작동을 하고 리캡챠 인증을 통과할 수 있게 해줍니다. 시간이 다소 걸리는 작업이기 때문에 이 부분에서 추가적으로 타임아웃 관리를 해줘야 합니다.
다음은 문자 인증입니다. 앞서 설명한 것처럼 유지 보수 비용을 줄이기 위해 추가적인 API 개발을 지양하자고 했지만, 문자 인증을 위한 서비스나 방법은 찾지 못했습니다. 결국 이 부분에서는 추가 API를 개발해야 했습니다.
문자 인증을 하려면 DB에 인증 코드 6자리가 존재하는지 확인해야 하는데, 이왕 만들 거면 노코드로 만들 수 있는 편리한 도구를 사용해 보고자 했습니다. ‘재피어’라는 유명한 자동화 서비스와 유사한 ‘n8n’ 오픈 소스입니다.
n8n에 대해 조금 더 설명해 볼까요? 업무 소통에 자주 사용하는 슬랙에서 대화를 주고받다 보면 그 대화가 바로 업무로 바뀌는 경우가 많습니다. 이런 경우 n8n을 사용하여 해당 대화에 로딩 이모지를 추가하면 그 대화 내용이 노션의 업무 리스트에 자동으로 추가되고, 로딩 이모지를 제거하고 완료 이모지를 추가하면 그 업무에 종료 표시가 설정 되도록 자동화한 적이 있습니다.
위 과정을 직접 코드로 개발할 수도 있지만, n8n을 사용하면 아래 그림처럼 UI 화면에서 드래그 앤 드롭으로 손쉽게 자동화할 수 있습니다. 그렇기 때문에 이 작업을 유지 보수하는 것도 비교적 쉽게 진행할 수 있습니다.
이러한 n8n으로 문자 인증 관련 작업도 자동화했습니다. DB에 전화번호를 넣으면 6자리 코드를 어디서 가져올지 정하고, 이 6자리 코드를 통해 인증하는 과정을 n8n으로 설정한 것입니다. 유지 보수도 손쉽게 할 수 있었습니다.
여기에 마지막으로 Playwright의 코드 생성을 잘 사용하면 거의 완벽한 테스트 코드를 작성할 수 있습니다.
지금까지 E2E 테스트에 대한 내용과 셀레늄, 퍼펫티어, Playwright와 같은 다양한 테스트 툴에 대해 알아보았습니다. 또한, 인증 관련 서비스 및 유지 보수 비용을 줄여 효율적인 테스트 코드를 작성하는 방법 역시 살펴봤습니다. 이제 다음 글에서는 E2E 테스트의 중요한 마지막 단계인 모듈화를 통한 재사용, 그리고 Playwright를 개선한 내용을 소개하려고 합니다.
지난 글에서 E2E 테스트과 이를 돕는 테스트 툴에 대해 알아보았습니다. 인증 관련 서비스를 통과하며 효율적인 테스트 코드를 작성하는 방법 역시 살펴봤습니다. 이번 글에서는 E2E 테스트의 중요한 마지막 단계인 모듈화를 통한 재사용, 나아가 Playwright를 다시 개선한 내용에 대해 알아보겠습니다.
모듈화 및 재사용
테스트 코드에서 모듈화란 무엇을 의미할까요?
예를 들어서 로그인하는 테스트 코드를 생성했다고 하면, 이 코드는 대부분의 많은 테스트에서 똑같이 쓰일 것입니다. 다만 결국 개발자가 이 코드를 수정하고 가공을 해서 모듈로 만든 다음, 다른 곳에 가져가서 써야 합니다. 테스트케이스 규격으로 인해 어쩔 수 없이 해야 한다지만, 제가 생각하기에 이런 방법은 완전한 자동화가 아닌 것 같았습니다.
직접 만든 테스트 자동화 도구
완전한 자동화를 위해 다양한 툴을 찾아봤습니다. 여러 노력에도 결국 마땅한 툴이나 라이브러리를 찾을 수 없었고, 그래서 직접 툴을 만들기로 했습니다. 아래 그림은 제가 일렉트론으로 구현한 테스트 자동화 도구입니다.
이 자동화 도구 좌측에는 테스트 케이스들이 있습니다. 여기서 테스트 케이스를 생성해 Playwright에 연동할 수 있습니다. 그리고 테스트 녹화 버튼을 누르면 평소 사용하는 대로 녹화를 하고, 녹화를 기반으로 테스트 코드가 생성됩니다. 이 테스트 코드를 1차 가공하고 나면, 아래 그림의 우측과 같이 변수가 생성됩니다.
사용자가 입력한 인풋 값들을 전부 추출해서 변수화시키고 이렇게 생성된 테스트 케이스 자체를 모듈로 사용하면,개발자의 추가 작업이 필요 없습니다. 어떤 도구를 사용하더라도 로그인 테스트 모듈을 재활용해서 사용할 수 있습니다.
이 기능을 구현할 때는 AST라는 개념과 기술을 사용했습니다. AST는 Abstract Syntax Tree의 약자로, 간단하게 설명하면 자바스크립트 등의 프로그래밍 언어를 트리 구조로 추상화한 구조입니다. 자세한 설명은 이 글을 참고해 주시면 감사하겠습니다. 위 테스트 자동화 도구에서는 사용자의 인풋 값을 추출할 때, 코드 자체를 조작하기 위해 사용했다고 생각하면 될 것 같습니다.
모듈화한 로그인 테스트 모듈은 어떻게 활용할까요? 사용 방법은 간단합니다. 아래 그림과 같이 새로운 테스트 케이스를 만들 때, 이전에 만든 로그인 모듈을 선택해서 새로운 테스트 케이스 앞에 배치하면 됩니다. 이렇게 하면 이후에 진행할 테스트 케이스에서 로그인을 위한 인풋 값을 포함한 테스트 케이스 전체를 사용할 수 있습니다.
이처럼 미리 테스트 케이스들을 모듈화해 두고, 화면에서 드래그 앤 드롭으로 여러 테스트 모듈을 연결해서 사용할 수 있습니다. 연결된 테스트 케이스로 시나리오를 만들고, 녹화하면서 순차적으로 테스트를 진행하면, 개발자의 도움을 최소화하여 손쉽게 테스트 코드를 생성할 수 있습니다.
지속 가능한 테스트 코드
1편에서 ‘지속 가능한 환경을 생성해 테스트하는 방법’에 대해 얘기한 적이 있습니다. 앞서 설명한 테스트 케이스 시나리오에서는 고정된 입력값을 테스트하면 두 번째 실행을 할 때 테스트가 실패하기 때문에 지속 가능한 환경이 아니게 됩니다.
쉽게 말해 주소록 생성을 위한 테스트 코드를 실행할 때, ‘FEConf 2024 주소록’이라는 입력값을 사용하면 처음에는 테스트가 성공하지만, 이 입력값이 키값으로 동작하는 경우에는 두 번째 테스트부터 실패하게 됩니다. 이런 실패를 막기 위해서는 개발자의 관리가 필요하게 됩니다. 즉, 코드를 수정하거나 DB에 입력된 값을 수정해야 하기 때문에 유지 보수 비용이 발생합니다.
이런 문제점을 해결하고 지속 가능한 테스트 코드로 사용하기 위해, 입력값들을 난수화시켜 테스트하는 방법을 고안했습니다. Faker라는 툴을 사용해서 입력값을 난수화 함으로써 매번 다른 주소록 제목을 나오게 하면, 여러 번의 테스트를 진행해도 테스트가 실패하지 않게 할 수 있습니다.
기본적으로 테스트 툴은 테스트 독립성을 깨지 않기 위해서 외부 변수를 받지 못하도록 되어 있습니다. 보통 모든 테스트 케이스를 만들 때 이렇게 제한을 하지만, 제가 툴을 만들 때는 굳이 그렇게까지 해야 하는지 의문이 들었습니다. 그래서 문제가 생기지 않는 범위 내에서 결과 데이터를 공유하거나 재사용하도록 개발했습니다.
예를 들어, 주소록 생성 테스트에서 주소록이 생성되면 고유한 ID 값이 존재하고, 이를 브라우저에 저장합니다. 이 ID 값을 로컬 DB에 저장하여 다음 테스트에 사용할 수 있도록 했습니다. A 테스트가 끝나고 만들어진 변수들을 B 테스트에 넘겨주고, 이 두 가지 테스트를 연결했을 때 정상적으로 동작하도록 했습니다.
Playwright 개선하기
이 모듈화 도구로 지속 가능한 테스트 코드를 작성하더라도, 10% 정도는 코드 수정이 필요했습니다. 마지막으로, 이것까지 개선하기 위해 셀레늄과 퍼펫티어를 수정한 경험을 바탕으로 Playwright도 개선하고자 했습니다.
Playwright의 셀렉터는 굉장히 좋은 기능을 가지고 있지만, 원하는 순서의 셀렉터를 선택할 수 있도록 바꿔보았습니다. 또, 결과 리포트 공유를 간편하게 만들어 다른 사람이 쉽게 확인할 수 있도록 만들고 싶었습니다. 추가로 체크 포인트부터 다시 시작할 수 있는 기능까지 구현했습니다.
결과 리포트
테스트 툴을 활용해 테스트를 진행하고 나면 리포트 파일이 생성됩니다. 이 리포트 파일은 일반적으로 개인의 PC에 저장되기 때문에, 공유하는 과정이 번거로울 때가 있습니다. 이런 번거로움을 덜기 위해 어떤 사용자가 어떤 작업을 하다가 실패했고, 어떤 상황에 문제가 생겼는지를 리포트에 기록하고, 이 리포트의 링크만 전송해서 쉽게 확인할 수 있도록 했습니다.
셀렉터 엔진 커스텀 조작
Playwright를 사용하다 보면 업데이트될 때 셀렉터를 자동으로 만들어 주는 부분이 버전마다 다르게 구현되어 있는 것을 확인할 수 있습니다. 한때 어떤 버전은 Placeholder 먼저 나오게 하는 경우도 있었습니다.
예를 들어 ‘이메일 주소’라는 것이 코드 값에 들어가 있을 때, 누군가 명칭을 바꾸게 된다면 이메일 주소 값을 찾을 수 없기 때문에 테스트 코드는 실패했습니다. 다행히 최근 버전에서는 인풋의 입력값을 name 어트리뷰트에 저장하도록 되어있습니다. 이렇게 되면 인풋 값에 무엇이 들어가더라도 성공하게 됩니다.
이 내용을 바탕으로 나머지 모든 부분에서도 name 어트리뷰트가 있다면, 이를 자동으로 먼저 생성하도록 했습니다. Playwright를 분석해 셀렉터의 우선순위를 정하는 코드를 찾았고, 특정 조건에 따라 name 어트리뷰트를 자동으로 생성하는 부분에 대부분 name 어트리뷰트를 사용해서 생성하도록 만들었습니다.
용어 사전
다만 이 방법을 사용하기 위해서는 모든 요소에 name 어트리뷰트를 넣어달라고 개발자에게 요청해야 하는 문제가 생깁니다. 다행히 위 서비스에서는 모든 텍스트들이 ‘Key : Value’ 쌍으로 구글 드라이브에 저장되어 있고, Key는 고정된 상태로 Value만 바꿔서 바인딩 하면 텍스트가 수정되도록 구현되어 있습니다. 따라서 키값이 변하지 않기 때문에 모든 테스트 케이스를 재활용해서 사용할 수 있습니다.
디자이너 또는 기획자가 화면을 기획하고 프론트엔드 개발자가 이를 구현할 때, 텍스트 수정의 경우 비효율적인 번거로운 과정을 거치는 경우가 생깁니다. 단순한 텍스트 수정 요청을 받더라도 디자이너가 피그마 결과물을 수정하고, 프론트엔드 개발자는 코드를 수정하고 배포하여 기획자와 디자이너에게 검토 받습니다.
이런 비효율적인 작업을 개선하기 위해서, 구글 드라이브의 스프레드시트에 Key, Value 쌍으로 텍스트를 매핑해두고 이 데이터를 읽어서 화면의 텍스트로 표현하도록 했습니다. 이렇게 하면 앞선 번거로운 과정을 거치지 않더라도, 기획자나 디자이너가 스프레드시트의 텍스트 값만 바꾸면 실시간으로 변경된 화면을 검토할 수 있습니다.
테스트 케이스의 체크포인트
테스트 케이스가 실패한 경우, 처음부터 다시 테스트한다면 번거로운 작업이 될 것입니다. 그래서테스트 케이스가 실패하더라도 특정 체크 포인트에서 다시 시작하도록 Playwright의 Session Storage API를 활용해서 체크 포인트 기능을 구현했습니다.
만약 테스트 케이스가 실패한 경우, 그 부분을 클릭하면 Session Storage API를 활용하여 실패하기 전의 상태를 기억하고 불러와서 그 부분부터 다시 시작할 수 있습니다.
테스트 스크린샷 비교
마지막으로 테스트 중에 저장된 스크린샷을 비교하는 과정에서 여러 가지 방해 요소들이 존재합니다. 예를 들어 아래 그림은 쿠버네티스를 모니터링하는 툴의 화면인데, 특정 조건에 따라 CSS 애니메이션으로 사용률에 따라 CPU 뒤의 물 배경이 차오르면서 화면이 변경됩니다. 이렇게 애니메이션이 많이 들어간다면 이전 스크린샷을 비교하는 것이 어려워집니다.
그래서 스크린샷을 저장하기 전에 CSS 애니메이션을 정지하도록 하는 코드를 추가했습니다. (Playwright에서는 기본적으로 이 기능을 지원합니다.)
동적인 화면도 문제가 생길 수 있습니다. 예를 들어 웹사이트에 노출하는 광고의 경우, 그때그때 동적으로 변하기 때문에 스크린샷을 비교하는 것이 힘들어집니다. 이를 해결하려면 동적인 요소는 제거하거나 숨겨서 테스트 스크린샷의 비교 대상에서 제외할 수 있습니다.
유저 플로우 생성
앞서 설명한 것처럼 테스트 리포트에는 다양한 정보들이 담겨있습니다. 저는 리포트에 담긴 다양한 정보들과 이 과정에서 저장된 스크린샷을 활용해서 유저 플로우를 그릴 수 있다고 생각했습니다. 이를 구현하고자 테스트 코드를 만들어서 실행만 하면 로그인 화면에서 대시보드로 이동했다거나, 어떤 버튼을 눌러 어떤 페이지로 이동했는지 등을 유저 플로우 화면으로 만들어 주는 기능을 개발했습니다.
아쉬웠던 점과 개선해야 할 점
여기까지, 테스트 툴을 만들었지만 여전히 아쉬웠던 점이나 더 개선하고 싶은 내용이 많이 남아있습니다.
가장 먼저, 독립적인 툴이 아닌 VS Code 플러그인으로 만들었으면 더 좋지 않았을까 하는 아쉬움이 있습니다.
또, 커스텀 리포트에 담긴 내용으로 무엇인가 해볼 수 있는 것이 많다고 생각합니다.
현재로는 네트워크 관련 기능들을 생각해 보고 있는데요, 쿠버네티스의 MOON이라는 도구를 사용해 로컬이 아닌 원격에서 테스트 케이스를 실행하도록 할 수도 있습니다. 이를 활용하면 대용량의 테스트를 원격에서 진행할 수 있습니다.
마지막으로 프론트엔드 렌더링 화면과 백엔드와의 API 간의 데이터를 수집해서, 어떤 화면에서 어떤 API를 사용했고, 이것의 영향도는 어떤지 파악할 수 있도록 개선해 보려고 합니다.
마치며
제가 만든 테스트 툴은 아직 부족한 점이 많이 있습니다. 쉽게 사용할 수 있도록 만들었지만 제3자가 사용하기에는 아직 어렵다고 생각됩니다. 지금까지 개발하면서 아쉬웠던 점들을 개선하고, 필요한 기능들을 추가해서 더욱 완성도 높은 테스트 자동화 툴을 만들고자 합니다.
물론 이번 글에서 설명한 개념들을 활용하면 테스트 툴이 없더라도 어느 정도 E2E 테스트를 쉽게 진행할 수 있습니다. 여러분도 제 작업 과정을 참고하여 E2E 테스트를 조금 더 효율적이고 간편하게 진행할 수 있기를 바랍니다.