E2E 테스트

실제 애플리케이션을 실행하여 전체 소프트웨어 시스템의 흐름을 검증하는 테스트

사용자의 입장에서 소프트웨어를 사용하면서 발생할 수 있는 모든 시나리오를 테스트하여 소프트웨어가 실제 환경에서 정상적으로 작동하는지 확인한다.

기존의 JS DOM에서 리엑트 테스팅 라이브러리의 도움을 받아 시뮬레이션 하던 것을 브라우저에 렌더링 된 실제 앱에서 실행하는 것이다. 직접 앱을 구동하기 때문에 다른 테스트에 비해 실행 시간이 오래 걸린다.

장점

단위 테스트나 통합 테스트는 모듈 단위의 테스트이기 때문에 사용자의 시나리오를 완벽하게 테스트 할 수 없는데 E2E 테스트는 사용자 관점에서 시나리오를 완벽하게 테스트할 수 있다.
프론트엔드부터 백엔드까지 앱의 전반적인 상태를 확인할 수 있다.
변경 사항이 전체 시스템에 미치는 영향을 확인할 수 있다.

E2E 테스트를 잘 작성하기 위해서는 백엔드와의 협력이 많이 필요하다. 용도에 맞는 테스트 데이터를 백엔드에서 미리 준비해주어야 E2E 테스트에서 활용할 수 있기 때문이다.
특별한 상황이 아니라면 MSW 모킹을 하지 않는 것이 좋다. 실제 API 응답을 활용하여 앱을 테스트하는 것이 진정한 E2E 테스트이기 때문이다. 또한, 모킹을 하여 E2E 테스트를 실행한다면 다양한 워크플로우 시나리오별로 모든 응답을 모킹하여 설정해야 하는데 시간도 오래 걸리고 비용도 많이 들기 때문이다.
프론트엔드와 백엔드의 전반적인 개발이 완료된 상태에서 도입해야 실행할 수 있다. API도 없고 프론트엔드도 일부 로직만 있는 경우 개바 단계에서 워크플로우 자체를 검증할 수 없기 때문이다. 따라서 E2E 테스트 도입을 위해 일정을 확보하는 것이 중요하다.

실제 웹 애플리케이션을 구동하여 테스트를 진행하기 때문에 렌더링, API 응답 등 각 작업 워크플로우를 직접 시뮬레이션 하기 때문에 많은 시간이 소요된다.

결국 테스트 실행시간이 길어지기 때문에 테스트를 피드백 받아 수정하는 시간도 증가하면서 개발 생산성이 떨어질 수 있다.

실제 API를 호출하기 때문에 네트워크에 문제가 있거나 백엔드 서버에 문제가 있는 경우 테스트가 실패한다.

또한 특정 기능을 테스트하기 위해 백엔드와 계속해서 협업해야 하고 백엔드의 요청 정보가 수정된다면 테스트에서 사용하는 정보도 변경되어 E2E 테스트가 깨질 수 있다.

즉, 백엔드의 직접적인 영향을 받아 테스트가 실패할 수 있다는 것이다.

테스트가 실패했을 때 원인을 찾아 수정하는데 오랜 시간이 걸릴 수 있다. 넓은 범위를 대상으로 검증하기 때문에 이슈가 발생했을 때 원인을 찾아 수정하는 시간이 더 오래 걸릴 수 밖에 없다.