A팀은 여러 가지 리팩토링을 수행하고 있습니다. 리팩토링 하기 전 단위 테스트를 철저하게 작성하고 인수 테스트 또한 철저하게 작성했습니다. 품질에 자신감이 생긴 A팀은 QA를 요청했습니다. 며칠 후 QA가 이야기 합니다. “이렇게 버그가 없는 프로젝트가 없었어요!” 바로 배포를 해도 좋다는 QA의 승인이 떨어집니다. 개발팀은 높은 자긍심을 느끼며 배포를 합니다. 그런데 잠시 후 고객문의가 폭주합니다. 서비스에 접속이 안 된다고 합니다. 당황하며 문제를 찾아봅니다. 아뿔싸! 배포 스크립트가 정상적으로 동작하지 않은 것입니다. 배포 스크립트는 소스상의 특정 파일을 읽어 배포를 진행하는데 이번 리팩토링에서 해당 파일을 사용되는 곳을 찾지 못해 지운 것이 이유였습니다.

위 예는 End-To-End 테스트의 필요성을 얘기하기 위해 지어낸 가상 사례입니다. 하지만 현실에서도 저런 일이 종종 발생합니다. 이 글을 보면 단위 테스트와 인수 테스트를 철저하게 작성한 것으로 인해 버그가 없었고 QA도 칭찬을 할 정도였습니다. 그러나 결국 배포를 할 때 문제가 발생하였습니다. 단기적인 관점에서 보면 잘만든 단위 테스트와 인수 테스트는 아무 소용이 없었고 고객은 리팩토링으로 인해 피해만 입은 것입니다. 이러한 일이 발생한 원인은 단위 테스트와 인수 테스트 그리고 QA조차도 검증할 수 없었던 영역이 있었다는 점입니다.

End-To-End 테스트는 서비스가 고객에게 서비스 되기 위해 거치는 모든 경로를 테스트하자는 취지를 가집니다. 즉 소스 코드의 품질 뿐 아니라 빌드, 배포, 웹서비스의 경우에는 웹서버까지 테스트하자는 것입니다. 

 

그림#1. 웹서비스에 적용 된 End-To-End 테스트의 예시

위 그림은 End-To-End 테스트의 예시를 보여줍니다. 하루마다 CI서버에서 End-To-End 테스트가 시작됩니다. 우선 빌드를 해서 컴파일 오류 등이 없는지 검사하고 단위 테스트를 수행하여 결함이 없는지 검사합니다. 만약 결함이 없다면 빌드 된 결과물을 배포 시스템을 이용하여 실제 웹서버와 동일하거나 유사한 환경을 가진 웹서버로 배포합니다. 마지막으로 CI 서버는 핵심 기능에 대한 검증을 하는 인수 테스트나 UI 테스트를 실행하여 방금 빌드해서 배포 한 결과물이 문제가 없는지 확인합니다.

만약 위와 같은 End-To-End 테스트가 미리 적용되어 있었다면 위 가상 사례의 문제는 어떻게 됐을까요? 문제의 파일을 지운 그날 일일빌드 시 배포가 정상적으로 되지 않았을 것입니다. 그리고 곧 이어 실행 된 UI 테스트는 배포가 되지 않아 정상적으로 실행되지 않고 실패 메일을 발송했을 것입니다. 개발자는 다음 날 결함이 있음을 발견했을 테고 문제를 조기에 발견할 수 있었을 것입니다.

End-To-End 테스트 역시 사람이 수동으로 수행할 수 있지만 다른 테스트와 마찬가지로 자동화하는 것이 좋습니다. 또한 단위 테스트와 마찬가지로 CI 서버와 통합하면 빠른 피드백을 받아 검증시점을 앞당길 수 있습니다. 다만 End-To-End 테스트는 보통 많은 시간이 걸리기 때문에 특별한 경우가 아니라면 커밋빌드 보다는 일일빌드에서 실행하는 것이 좋다고 생각합니다. 방금 위에서 소개했던 그림이 좋은 모델이 될 수 있으리라 봅니다.