단위 테스트/통합 테스트와 비교하여 E2E 테스트는 테스트 세부 사항이 부족하더라도 더 적은 코드로 더 많은 테스트 시나리오를 다룰 수 있습니다.

모든 프로젝트가 E2E 테스트 작성에 적합한 것은 아닙니다. 다음 사항은 프로젝트가 E2E 테스트에 적합한지 판단하는 데 도움이 될 수 있습니다.

• 프로젝트 주기가 길어요. E2E 테스트를 작성하는 데는 많은 시간과 에너지가 소모됩니다. 장기적인 유지 관리 프로젝트가 아니라면 투자할 필요가 없습니다.

• 프로젝트 반복 빈도가 높습니다. 반복 간격이 매우 길고 테스트 시간과 인력이 충분하다면 세심한 수동 인터페이스 테스트가 더 안정적일 것입니다.

• 페이지 구조가 안정적입니다. E2E 테스트는 일반적으로 요소를 찾는 방법으로 CSS/XPath 선택기에 의존합니다. 페이지의 DOM 분해가 자주 변경되면 테스트 사례 유지 비용이 증가합니다.

또한 다음 시나리오에서 E2E 테스트의 효과가 더 좋습니다.

• 순전히 정적인 페이지, 콘텐츠가 변경되지 않는 페이지가 바람직합니다. 브라우저 수준에서 스크린샷을 찍고 전후 두 반복의 스크린샷을 비교하여 변경 사항으로 인해 페이지의 최종 표시가 손상되었는지 또는 디스플레이 변경 사항이 예상과 일치하는지 확인할 수 있습니다.

• 호환성 테스트. 다양한 브라우저에서 프로젝트의 호환성을 테스트해야 하는 경우 E2E 테스트를 사용하여 한 번에 여러 다른 브라우저를 다룰 수 있습니다.

• 상호작용은 복잡하고 상호작용 단계가 많습니다. 예를 들어, 복잡한 다단계 양식을 작성할 때 수동 작업 비용이 클수록 E2E를 사용하여 자동으로 완료하면 더 큰 이점을 얻을 수 있습니다.
  하지만 다른 테스트와 마찬가지로 테스트 프로세스에 데이터가 기록되어 있는 경우 다시 실행할 때 일관된 환경을 보장하기 위해 테스트가 완료된 후 기록된 데이터를 지워야 합니다.

설명서는 실수할 수도 있지만 기계가 더 안정적입니다. 특히 일부 핵심 비즈니스 페이지의 경우 인력을 방출하는 것이 매우 중요하므로 모든 상황을 다루기가 어렵기 때문에 E2E가 이 문제를 해결합니다.

그런데 Angular를 사용하면 E2E 작성이 더 재미있어요