원문: https://testing.googleblog.com/2016/09/testing-on-toilet-what-makes-good-end.html (Translated by Google Gemini)

End-to-end(E2E) 테스트는 시스템의 한쪽 끝에서 다른 쪽 끝까지, 그 사이의 모든 것을 블랙박스로 취급하며 전체 시스템을 테스트합니다. E2E 테스트는 시스템 전반에 걸쳐 나타나는 버그를 잡아낼 수 있습니다. 단위 테스트, 통합 테스트와 더불어 E2E 테스트는 균형 잡힌 테스트 식단의 핵심적인 부분이며, 운영 환경과 거의 유사한 상태에서 시스템의 건전성에 대한 확신을 줍니다.

하지만 안타깝게도, E2E 테스트는 단위 테스트나 통합 테스트보다 느리고, 불안정하며(flaky), 유지보수 비용이 더 비쌉니다. E2E 테스트가 필요한지, 만약 그렇다면 어떻게 작성하는 것이 최선일지 신중하게 고려해야 합니다.

다음과 같은 “로그인 플로우"에 대한 E2E 테스트가 어떻게 작동할지 생각해 봅시다:

login_flow

비용 효율성을 높이려면, E2E 테스트는 더 작은 단위의 테스트로는 안정적으로 평가할 수 없는 시스템의 측면에 집중해야 합니다. 예를 들어 자원 할당, 동시성 문제, API 호환성 등이 그렇습니다.

더 구체적으로 살펴보겠습니다.

  • 각각의 중요한 유스케이스마다, 그에 상응하는 E2E 테스트가 하나씩 있어야 합니다. 여기에는 중요한 종류의 오류 각각에 대한 테스트가 하나씩 포함되어야 합니다. 목표는 전체 E2E 테스트의 개수를 낮게 유지하는 것입니다.
  • 느리고 불안정한 의존성이나 사소한 UI 변경과 같은 문제에 직면했을 때 E2E 테스트를 안정적으로 유지하기 위해, 테스트당 분기에 최소 일주일의 시간을 할애할 준비를 해야 합니다.
  • 구체적인 구현 세부사항보다는 전체적인 시스템 동작을 검증하는 데 노력을 집중하세요. 예를 들어, 로그인 동작을 테스트할 때는 정확한 메시지나 시각적 레이아웃(이것들은 자주 바뀔 수 있습니다)과는 독립적으로 프로세스가 성공하는지를 검증해야 합니다.
  • E2E 테스트를 디버깅하기 쉽게 만드세요. 개요 수준의 로그 파일을 제공하고, 일반적인 테스트 실패 모드를 문서화하며, 모든 관련 시스템 상태 정보(예: 스크린샷, 데이터베이스 스냅샷 등)를 보존하는 것이 좋습니다.

E2E 테스트에는 몇 가지 중요한 주의사항도 따릅니다.

  • 다른 팀이 소유한 시스템 컴포넌트가 예기치 않게 변경되어 여러분의 테스트를 깨뜨릴 수 있습니다. 이는 전체적인 유지보수 비용을 증가시키지만, 호환되지 않는 변경 사항을 발견하는 계기가 될 수도 있습니다.
  • E2E 테스트는 종종 기반 의존성에 대한 여러 테스트 더블(페이크나 스텁)을 필요로 합니다. 하지만 시간이 지남에 따라 실제 구현과 달라지면서 높은 유지보수 부담을 가질 수 있습니다.
  • 가능한 한 테스트 데이터는 일시적(ephemeral)으로 유지하세요. 영구적인 테스트 데이터는 다른 테스트나 시스템 사용자와 충돌할 수 있으며, 테스트를 다시 실행하기 전에 시스템을 알려진 상태로 재설정하는 것이 어려울 수 있습니다.