인수 테스트와 E2E 테스트 차이

🪧 summary

“인수 테스트랑 E2E 테스트랑 구분하는 기준이 뭘까?”

3대 450(치던) 인비가 갑작스레 인수 테스트와 E2E 테스트의 차이를 궁금해했다. 우아한테크코스 레벨1~2 때도 자주 거론 되었는데, 수료한 상태에서 다시 고민을 해보니 흥미로운 주제였다.

우리는 백엔드를 개발하기 때문에 우리의 클라이언트 대부분은 프론트엔드다. 프론트엔드가 기대하는 API가 제대로 기능하는지 검증하기 위해서 인수 테스트를 작성하면 E2E 테스트와 거의 동일한 형태로 테스트가 작성된다. 때문에 나도 레벨1~2 기간에 둘의 차이가 무엇인지 이해하지 못하고 한참 고민했던 것 같다. 고민한 끝에 ‘관점의 차이’로 결론을 지었었는데, 그 기준은 아래와 같다.

🪧 E2E(End-to-End) 테스트

E2E 테스트는 테스트하고자 하는 기능에서 필요로 하는 모든 컴포넌트들이 올바르게 협업해서 최종적으로 원하는 결과를 내는지 확인하는 테스트다. 아래와 같이 아키텍쳐가 나누어진 서비스에서, 하나의 기능을 검증한다고 가정해보자.

해당 기능에서 End-to-End 검증을 위해 Controller - Service - Repository를 모두 사용한다고 하면, 모든 컴포넌트들의 협업을 검증한 것이므로 E2E 테스트라고 부를 수 있을 것이다. 만일 셋 중 하나라도 모킹을 하거나, Service - Repository 까지만 테스트를 진행하면 E2E 테스트라 보기 어렵다.

만일 애플리케이션이 굉장히 작고 단순해서, 작은 단위 테스트 수준으로 기능 검증이 가능하다면 어떨까? 이 테스트도 E2E 테스트로 보아야 할까?

내 생각은 ‘그렇다’이다. 검증하고자 하는 기능의 동작에 필요한 컴포넌트가 모두 포함된다면, 그 테스트 또한 E2E 테스트로 볼 수 있다고 생각한다.

물론 이런 경우가 흔치는 않을 것이다. 대부분의 애플리케이션에서 말하는 ‘기능’은 서비스를 운영하기 위한 시스템과, 여러 가지 프로세스들이 뒤섞이기 때문에 그 범위가 굉장히 클 것이다.

🪧 인수(Acceptance) 테스트

인수 테스트는 테스트하고자 하는 기능을 비즈니스적인 관점에서 올바르게 동작하는지 확인하는 테스트다. 즉 테스트 구조가 어떤지, 어떤 컴포넌트가 포함되는지 등 기술적인 관점과 전혀 상관없이 클라이언트가 기대하는 동작에 대한 검증이 중요하다.

앞서 E2E 테스트와 완전히 동일한 가운데, ‘클라이언트가 기대하는’ 이라는 명제가 붙으면 그게 인수 테스트가 된다. 대부분의 웹 서비스 백엔드 API 개발자에게 클라이언트란 프론트엔드고, 프론트엔드가 API를 요청했을 때 기대하는 결과를 전달하는 모양이 E2E 테스트와 동일하기 때문에 E2E 테스트 == 인수 테스트 라고 많이들 생각하게 되는거 같다.

이번엔 조금 다른 예시를 생각해보자. 서비스 규모가 굉장히 큰 계좌송금 애플리케이션에서, 송금 금액을 계산하는 기능의 단위 테스트가 존재한다. 이 테스트는 인수 테스트가 될 수 있을까?

역시 내 생각은 ‘그렇다’이다. 인수 테스트는 테스트나 애플리케이션의 규모와 상관없이 클라이언트의 기대가 포함되면 모두 인수 테스트가 될 수 있다고 생각하기 때문이다. 즉, 흔히들 이야기하는 단위 테스트 / 통합 테스트 / E2E 테스트 모두 인수 테스트가 될 수 있다.

🪧 결론

E2E 테스트는 기술적인 관점에서, 인수 테스트는 비즈니스적인 관점에서의 테스트로 구분지었다. 웹 서비스 백엔드 개발자 입장에선 두 테스트를 비슷하게 구성하게 되는 경우가 많아 말장난처럼 느껴지기도 하는거 같다.

면접관님들이 “인수 테스트, 통합 테스트, 단위 테스트로 구분지은 이유가 뭔가요?” 라고 물으시면 이야기할 거리가 한 가지 더 생긴거 같다. 재밌다!