E2E 테스트란 ?
E2E 테스트란 ? E2E 테스트 과정에서는 실제 사용자의 시나리오를 테스트함으로써 애플리케이션 동작을 테스트하게되고,또한 프론트엔드에서 OS와 브라우저엔진 환경이 달라서 발생하는 크로스 브라우징 이슈를 E2E 테스트를 통해 미리 방지할 수 있습니다.
이 테스트를 통과함으로써 애플리케이션의 무결성을 증명할 수 있게 됩니다.E2E 테스트는 End To End의 약자로 애플리케이션의 흐름을 처음부터 끝까지 테스트하는 것을 의미합니다.
React 에서의 테스팅도구 ?
React 에서 가장 많이 사용하는 테스팅 도구는 cypress다.
하지만 요즘에 playwright 가 뜨기 시작하면서 찾아보니 cypress에서 playwright 로 옮기는 개발자들도 늘고 있는 것 같다.
Cypress의 장점으로는 사용법이 직관적이고 테스트 환경 구축이 쉬우며 ,테스트 과정과 결과를 시각적으로 확인 가능하여 디버깅이 용이하다.
또한 커뮤니티가 가장 활발한 프레임워크라서 내부적인 지원이 안되는 기능이라도 다양한 플러그인을 통해서 구축이 가능합니다.
그러나, 단점으로는 모든 테스트가 직렬로 실행되므로 테스트의 갯수가 증가할수록 시간이 오래 걸린다는 점과
( 병렬 처리 기능의 경우 유료 플랜 & 외부 플러그인을 사용해서 테스트 속도 보완 가능하지만 외부 플러그인을 사용하는 만큼 번거로운 설정 필요 )
크로미움 기반의 브라우저, Firefox 2가지의 브라우저만 지원하며, 모바일 환경을 제공하지 않는다는 단점이 존재한다.
반면에 Playwright는 유료로 병렬 처리를 지원하는 Cypress에 비해 무료로 병렬 처리를 지원하여 이로인해 Cypress에 비해 더 빠른 테스트 실행이 가능하다.
또한 Cypress에는 지원하지 않는 자동화 도구 다중탭(멀티 탭) 기능을 지원하여 여러 탭으로 나누어 테스트를 진행할 수 있는 점
다중 브라우저를 지원하여 Chrome, Firefox, Safari를 포함한 다양한 브라우저에서 테스트를 실행할 수 있으며 모바일 환경을 제공하며 , 크로스 플랫폼 테스팅이 가능하여 Windows,Mac,Linux에서 동일한 테스트 스크립트를 사용할 수 있다는 장점이 존재합니다.
Playwright의 단점은 다양한 브라우저와 플랫폼을 지원하기 때문에 설정이 복잡하다는 부분과 자료를 찾을 수 있는 커뮤니티가 부족하다는 점이 꼽히지만, 챗Gpt 에 PlayWright 전용 GPT 가 존재하여 이를 잘 활용하면 자료 부족 문제는 해결될 것 같다.
프로젝트 요구 사항이나 팀의 선호도에 따라 적합한 도구의 선택이 필요하다.
나는 이번에 공부를 하기위해 둘 중 하나만 선택하여 E2E 테스트를 해보기로 했는데,
성능과 비용적인 측면에서 바라봤을 때는 Cypress에 비해 Playwright가 좀 더 유리하다고 판단하여 Playwright를 선택하게 되었다.
Playwright 시작하기
설치하기
npm init playwright@latest
아래와 같이 타입스크립트나 깃허브 액션 workflow도 설정할 수 있다.
그리고 vsCode의 확장 프로그램도 추가하면 더 간단하게 작업할 수 있다.
설치하면 요런 모양의 아이콘이 왼쪽에 생기는데
그걸 클릭하면 테스트 탐색기가 뜬다.
여기서 이제 제일 왼쪽에 재생버튼을 누르면 테스트가 실행된다.
두번째는 테스트 디버그 버튼임
그러면 테스트는 어떻게 진행하는가?
E2E 테스트는 위에 설명했다싶이 사용자의 시나리오를 테스트 하는 것이라고 했다.
그래서 그 시나리오를 코드로 짜주면 되는것임.
아까 playwright를 설치하면서 tests라는 폴더도 생성됐을건데, 그 아래에 테스트 코드를 추가한다.
내가 만들어 둔 기능을 설명하자면 회원가입시에 있는 주소 검색 모달이다.
회원가입 폼에서 [주소검색] 을 클릭하면 모달이 띄워지고 그 모달에서 검색창에 자신의 주소를 입력 후에
enter키 이벤트가 발생하면 거기서 주소를 골라서 선택하면 주소 input 에 선택한 주소와 우편번호가 자동으로 입력되는 기능을 가지고 있다.
그 시나리오를 코드로 구현하면 아래와 같다.
import { expect, test } from '@playwright/test';
test.describe('Address search E2E test', () => {
test.use({ locale: 'ko-kr' });
test('should search and select an address', async ({ page }) => {
// 페이지 이동
await page.goto('http://localhost:3000/client');
// 주소 찾기 버튼 클릭 -> 모달이 열려야 함
await page.click('button:has-text("주소 찾기")');
// 주소 검색 인풋에 "부암동" 입력
const searchInput = page.locator(
'input[placeholder="주소를 입력해주세요."]'
);
await searchInput.fill('송정동');
// Enter 키 이벤트 발생
await searchInput.press('Enter');
// 주소 검색 결과를 기다리고, 결과 중 하나를 선택
const firstResult = page.locator('text=송정1동').first();
await expect(firstResult).toBeVisible();
await firstResult.click();
// 모달이 닫히고, 폼에 주소가 입력되었는지 확인
await expect(page.locator('input[name="roadAddr"]')).toHaveValue(
'부산광역시 송정1동.......)'
);
// 실제 ZIP 코드를 확인하여 대체 (예: 'ZIP_CODE_HERE')
await expect(page.locator('input[name="zipNo"]')).toHaveValue('11111');
});
});
이렇게 작성하고 아까와 같이 테스트아이콘을 눌러서 테스트를 진행해본다.
정상적으로 통과하면 아래와 같이 초록불이 뜨는데
에러가 발생하면 붉은불이 ;;;;;;;;;생겨서 ;;; 불안해진다ㅋㅋ... 뭐가 잘못됐나...
그리고 이제 나는 이 테스트를 깃허브에 push 할 때마다 실행하고 싶어서 CI 를 적용해볼려고 한다.
CI란?
CI는 간단히 요약하면 빌드/테스트 자동화 과정이다.
CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결 할 수 있음
커밋할 때마다 빌드와 일련의 자동 테스트가 이루어져 동작을 확인하고 변경으로 인해 문제가 생기는 부분이 없도록 보장한다.
Playwright CI 설정 공식문서
https://playwright.dev/docs/ci-intro
그래서 깃허브에 actions에서 워크플로우를 생성하여 CI 설정을 해보도록 한다.
테스트 자동화하고자 하는 폴더 내에 아래와 같이 workflows 를 만들어준다.
그리고 playwright.yml 파일내에 설정을 해주면됨
name: Playwright Tests # 워크플로우 이름: Playwright 테스트
on:
push:
branches: [main] # main 브랜치로 push 될 때 이 워크플로우가 실행됨
jobs:
test:
timeout-minutes: 60 # 최대 실행 시간 60분 설정
runs-on: ubuntu-latest # 최신 Ubuntu 환경에서 실행
steps:
- uses: actions/checkout@v4 # GitHub 액션: 코드 체크아웃 (현재 리포지토리를 가져옴)
- uses: actions/setup-node@v4 # GitHub 액션: Node.js 환경 설정
with:
node-version: lts/* # LTS(Long Term Support) 버전의 Node.js 사용
- name: Install dependencies # 의존성 설치 단계
run: yarn install # yarn을 사용해 프로젝트 의존성 설치
- name: Install Playwright Browsers # Playwright 브라우저 설치
run: npx playwright install --with-deps # Playwright 브라우저와 필요한 종속성 설치
- name: Start development server # 개발 서버 시작
run: yarn dev & # 백그라운드에서 개발 서버 실행
env:
CI: true # CI 환경에서 실행되도록 환경 변수를 설정
- name: Wait for server to be ready # 서버가 준비될 때까지 대기
run: npx wait-on http://localhost:3000 # 서버가 실행될 때까지 localhost:3000 대기
- name: Run Playwright tests # Playwright 테스트 실행
run: npx playwright test
- uses: actions/upload-artifact@v4 # 테스트 결과 보고서 업로드
if: always() # 테스트 성공 여부에 상관없이 항상 실행
with:
name: playwright-report # 업로드할 아티팩트 이름 지정
path: playwright-report/ # Playwright 보고서 경로
retention-days: 30 # 업로드된 파일이 30일간 유지됨
위에는 yarn을 기준으로 작성했는데 아래는 npm으로 작성함
name: Playwright Tests
on:
push:
branches: [main]
jobs:
test:
timeout-minutes: 60
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: lts/*
- name: Install dependencies
run: npm ci
- name: Install Playwright Browsers
run: npx playwright install --with-deps
- name: Start development server
run: npm run dev &
env:
CI: true
- name: Wait for server to be ready
run: npx wait-on http://localhost:3000
- name: Run Playwright tests
run: npx playwright test
- uses: actions/upload-artifact@v4
if: always()
with:
name: playwright-report
path: playwright-report/
retention-days: 30
이렇게 작성하고 커밋 후 깃허브 레포 -> actions로 이동하면
이렇게 workflows가 생성되고 제일 위의 커밋과 같이 (노란색) 테스트가 진행중인것을 확인가능하다.
에러의 경우 아래와 같이 붉은 색으로 뜨는데
어디에서 에러가 났는지 확인을 하려면
에러난 부분을 클릭해서 에러난 부분을 펼쳐보면된다.
이런 식으로 뜸
그리고 그 에러난 부분에 대해서 리포트를 다운받아서 자세히 ? 확인해 볼 수 있는데
summary -> Artifacts에서 playwright-report를 클릭하면 zip파일이 다운받아진
zip을 열어서 확인해보면
위와 같이 어떤 부분에서 에러가 발생했는지 확인가능하고 상세보기도 가능하다.
그래서 그 부분을 수정하거나 설정을 손보면 됨
나는 설정에 문제가 있었어서 여러 번 손봤다...
무튼 성공하면 요롷게 보기 좋게 뜬다..
참고자료
https://www.axelerant.com/blog/cypress-selenium-playwright
https://shorttrack.tistory.com/7
https://velog.io/@heelieben/E2E-%ED%85%8C%EC%8A%A4%ED%8A%B8-PlayWright-2eub88ik
'STUDY' 카테고리의 다른 글
[라이브러리] react-spring 애니메이션 구현 (1) | 2024.09.29 |
---|---|
[라이브러리] react hook form 유효성 검사하는 폼 만들기 (2) | 2024.09.18 |
[react-signature-canvas] 전자서명 구현하기 (1) | 2024.09.13 |
axios 인스턴스 (0) | 2024.09.10 |
session 방식의 개념 및 한계와 JWT token 인증 방식 (0) | 2024.09.04 |