해당 포스트는 주관적인 내용이 많이 담겨 있습니다.
별도의 사용법은 다루지 않습니다.
함수, 컴포넌트에 대한 단위, 통합 테스트에 이어서 페이지 단위 E2E 테스트를 진행하였다.
Playwright
E2E 테스트를 진행할 때 주로 Cypress 나 Playwright 를 사용한다고 해서 둘 중에 어떤 것을 써야 되는지 고민했었다.
두 라이브러리에 대해 공식 문서나 블로그 등을 찾아보면서 장단점을 알아보면서 두 가지 정도의 차이로 인해 Playwright 를 사용하기로 하였다.
해당 포스트는 회고 중심의 내용이기 때문에 별도의 포스팅을 통해서 두 개의 라이브러리의 특징을 정리할 계획이다.
문법의 익숙함
Cypress 의 예제 테스트 코드를 봤을 때 낯설다는 느낌을 받았지만 Playwright 는 이런 느낌을 받지 못했다. 물론 Cypress 도 사용을 하다 보면 익숙해지겠지만 뭔가 러닝 커브가 존재한다는 부분에서 좋은 느낌을 받지 못했다.
예를 들어 화면에서 button 태그를 선택한다고 했을 때의 각각의 라이브러리는 이런 식으로 선택할 수 있다.
Playwright 의 경우 React Testing Library 와 비슷한 방식으로 선택할 수 있어 테스트 코드 작성 시 큰 어려움이 없었다.
브라우저 설치
처음에 Cypress 환경 설정을 하고 동작 테스트를 진행할 때 테스트할 브라우저를 선택하는 과정에서 Firefox 가 보이지 않아서 당황했던 적이 있었다.
이 부분은 Cypress 는 실제 브라우저 환경에서 테스트를 진행하는데 내 컴퓨터에 Firefox 가 설치되어 있지 않아서 발생하는 이슈이다.
개인적으로 환경이 바뀔 때마다 필요한 브라우저를 별도로 설치하는 것을 선호하지 않아 CLI 를 통해 브라우저를 설치할 수 있는 Playwright 를 선택하였다.
작업 중점 사항
사용자 관점 테스트
E2E 테스트는 사용자 관점에서 전체 흐름을 테스트 하는 것을 의미한다.
그렇기 때문에 테스트 코드를 작성할 때 최대한 사용자 관점에서 작성하려고 노력하였다.
예를 들어 버튼의 disabled 상태에 대한 테스트 코드를 작성하는 경우, 사용자 관점이 아닌 개발자 관점으로 테스트 코드를 작성하면 이런 목표로 작성될 수 있다.
“버튼이 disabled 상태가 된다."
이 테스트를 사용자 관점으로 변경하면 이런 목표로 작성할 수 있다.
“버튼이 클릭 되지 않는다.”
소통 중심 메시지 작성
이 부분은 통합, 단위 테스트와 마찬가지로 테스트 케이스 이름 작성 시 소통을 원활하게 할 수 있도록 최대한 풀어서 작성하려고 노력하였다.
DAMP 원칙 준수
이 부분도 통합, 단위 테스트와 마찬가지로 DRY 원칙보다는 DAMP 원칙을 준수하여 직관적인 테스트 코드 파악을 중점으로 테스트 코드를 작성하였다.
고민
중복된 테스트 영역
만약 메인 페이지에서도 포스트 아이템이라는 영역이 존재하고 포스트 페이지에서도 동일한 위치에 포스트 아이템 영역이 존재하는 경우, 포스트 아이템 관련 테스트 코드를 메인 페이지의 테스트 코드에도 작성해야 하고 포스트 페이지의 테스트 코드에도 작성해야 하는지에 대한 고민을 했었다.
포스트 아이템 영역에 대한 테스트 케이스가 생각보다 많아서 각 페이지의 테스트 파일에 포스트 아이템 영역의 테스트 케이스를 중복으로 작성하게 되면 유지보수가 힘들어질 것 같다는 생각이 들었다.
그래서 이 문제를 포스트 아이템 영역에 대한 테스트를 별도의 테스트 파일로 분리하고 페이지를 순회해서 테스트를 진행하기로 하였다.
느낀점
- Playwright 를 프로젝트에 설정하면 예제 E2E 테스트 코드가 생기는데 이 예제 코드에 라이브러리 사용법이 잘 작성되어 있어 초반에 많은 도움이 되었다.
- 초반 E2E 테스트 코드 작성 시 UI Mode 를 통해 내가 작성한 테스트를 눈으로 직접 보면서 어떻게 동작하는지 파악할 수 있어서 많은 도움을 받았다.
- 단위, 통합 테스트 코드를 작성할 때처럼 given-when-then 패턴을 동일하게 적용해서인지 아니면 비슷한 문법인 Playwright 를 사용해서인지 몰라도 E2E 테스트를 작성할 때 크게 어려웠던 점은 많이 없었다.
- 확실히 기존 테스트와 다르게 실제 페이지를 기준으로 테스트를 진행하기 때문에 테스트에 대한 신뢰가 더 높았고, 기존 테스트에서 테스트하지 못했던 기능들에 대해 더 쉽게 테스트할 수 있었다. (e.g. 다크/라이드 모드 변환)
- QA 팀이 따로 존재하지 않는 회사에서 근무한 적이 대다수라 개발자 또는 직원분들과 함께 QA 를 자체적으로 진행한 적이 많았다. 이때 낭비되는 시간과 반복적인 테스트로 인한 테스트 누락 등의 문제가 가끔 발생했었는데 E2E 테스트를 도입하면 이런 문제점들을 해결할 수 있겠다는 생각이 들었다.
- 장점도 있지만 확실히 단위, 통합 테스트보다 테스트 코드 작성에 대한 작업량이 많다는 점을 느꼈다.
참고
