E2E 테스트

테스트는 원래 부품 단위로 돌렸습니다. 금액을 계산하는 함수에 값을 넣어 결과를 보고, 화면 하나를 떼어 버튼이 눌리는지 봤습니다. 빠르고 값이 싸서 이천 개를 모아 돌려도 1분이 안 걸립니다. 그런데 이 이천 개가 전부 초록불인 날에도 사용자가 서비스를 못 쓰는 일이 있었습니다.

부품이 멀쩡해도 이어지는 자리가 끊어지면 사용자에게는 고장입니다. 로그인도 되고 문서 저장도 되는데, 로그인 뒤에 넘어가는 주소가 한 글자 틀려서 저장 화면까지 못 가는 식입니다. 함수를 하나씩 떼어 보는 테스트는 이 끊김을 끝내 못 봅니다. 함수는 각자 제 일을 했기 때문입니다.

페이지덱에서도 같은 일이 있었습니다. 태오가 금요일에 테스트가 전부 통과한 것을 확인하고 배포했는데, 월요일 아침에 수아가 "가입한 고객이 첫 문서를 못 만든다" 고 알려 왔습니다. 가입 직후에만 권한 정보가 늦게 붙어서 첫 시도가 막히는 상황이었습니다. 어느 부품도 고장 나지 않았고, 사용자가 밟는 순서대로 눌러 본 사람만 없었습니다.

E2E 테스트는 그 순서를 기계에게 밟게 한 것입니다. 사람이 앉아서 하던 확인, 그러니까 브라우저를 열고 가입하고 로그인하고 문서를 만들어 보는 일을 코드로 적어 두고 배포할 때마다 돌립니다. 이름이 말하는 양 끝은 사용자의 손가락과 화면에 돌아오는 결과이고, 그 사이에 무엇이 끼어 있든 묻지 않습니다.

확인할 흐름 하나를 고르고, 사용자가 밟는 순서대로 조작을 코드에 적고, 마지막에 무엇이 보여야 하는지를 못 박습니다. 여섯 단계로 나뉩니다.

1. 흐름 고르기 — 가입부터 첫 문서 저장까지처럼 시작과 끝이 분명한 경로 하나를 잡습니다. 화면이 아니라 목적이 단위입니다. 이 경로를 그림으로 정리해 둔 것이 유저 플로우라서, 그 문서가 있으면 무엇을 옮길지 고르기가 빠릅니다.
2. 시작 상태 준비 — 어떤 계정과 어떤 데이터가 있는 상태에서 시작할지를 맞춰 둡니다. 미리 깔아 두는 이 상태를 픽스처라고 하고, 매번 손으로 만들지 않고 한 번 적어 두고 불러 씁니다. 여기가 흔들리면 어제 통과한 테스트가 오늘 이유 없이 실패합니다.
3. 조작 적기 — 브라우저를 대신 조작해 주는 도구에 순서를 적습니다. 주소를 연다, 이메일 칸에 값을 넣는다, 가입 버튼을 누른다, 화면이 바뀔 때까지 기다린다 같은 줄이 이어집니다.
4. 기댓값 못 박기 — 무엇이 보여야 성공인지를 적습니다. 화면이 넘어갔다는 것만으로는 부족하고, 방금 만든 문서의 제목이 목록에 떠 있다는 식으로 사용자가 눈으로 확인할 것을 씁니다.
5. 자동 실행에 걸기 — 사람이 생각날 때 돌리면 결국 안 돌립니다. 코드 변경을 자동으로 검증하고 배포까지 잇는 체계인 CI/CD에 붙여, 코드가 올라올 때마다 저절로 돌게 둡니다.
6. 실패 증거 남기기 — 실패한 순간의 화면 사진과 영상, 서버 기록을 함께 남깁니다. 이 증거가 없으면 원인 찾기에 실행 시간보다 긴 시간이 듭니다.

잘 맞는 자리는 틀렸을 때 손해가 큰 흐름입니다. 가입, 결제, 권한 부여처럼 한 번 막히면 사용자가 떠나거나 돈이 어긋나는 경로입니다. 결제 한 건이 화면과 서버와 카드사와 메일 발송을 차례로 거친다면, 그 연결을 통째로 확인하는 방법은 사실상 이것뿐입니다. 고친 뒤에 원래 되던 것이 그대로 되는지 보는 회귀 테스트의 바깥 껍데기로도 알맞습니다.

한계는 셋입니다. 첫째로 느립니다. 브라우저를 띄우고 화면이 그려지기를 기다리니 한 건에 10초쯤 걸리고, 500개를 두면 한 바퀴에 두 시간이 넘습니다. 아무도 기다리지 않는 검사는 결국 꺼집니다.

둘째로 잘 깨집니다. 버튼 문구를 "저장" 에서 "저장하기" 로 바꾸기만 해도 실패하고, 서버가 0.5초 늦게 답해도 실패합니다. 코드를 안 고쳤는데 어떤 날은 통과하고 어떤 날은 실패하는 플레이키 테스트가 가장 많이 나오는 자리가 E2E 입니다.

셋째로 원인을 짚어 주지 않습니다. 단위 테스트는 실패하면 함수 하나를 지목하지만, E2E 는 그 흐름에 얽힌 수십 개 중 어디가 문제인지를 사람이 파야 압니다.

그래서 개수를 일부러 적게 유지합니다. 단위 테스트는 수천 개를 두고 E2E 는 가장 비싼 흐름 몇십 개만 둡니다. 비율을 뒤집으면 검사 한 바퀴가 반나절이 됩니다.

"이 기능 E2E 하나만 붙여 주세요. 결제까지 가는 거라 안 되면 티 바로 납니다."

중요도가 높은 흐름이니 개수를 늘리더라도 여기는 덮자는 요청입니다.

"E2E 가 빨간불인데 로컬에서는 되는데요?"

기능이 아니라 테스트 환경이나 대기 시간 문제일 수 있다는 뜻이고, 대개 플레이키를 의심하는 말입니다.

"E2E 는 야간에만 돌리고, 올릴 때는 단위랑 통합만 볼게요."

전체 실행이 길어져서 빠른 검사와 느린 검사를 분리하겠다는 결정입니다.

페이지덱에서는 E2E 를 마흔 개쯤 두고 있습니다. 가입, 결제, 문서 공유, 권한 변경 네 흐름이 대부분이고, 코드가 올라오면 단위와 통합이 먼저 돌고 E2E 는 병합 직전에 돕니다. 태오가 새 기능마다 E2E 를 붙일지 정하는 기준은 기능의 크기가 아니라 막혔을 때 수아에게 전화가 오느냐입니다.

지현은 다른 쪽을 봅니다. 최근 두 주 동안 E2E 실패 스무 번 중 실제 버그가 세 번뿐이면, 테스트를 더 붙일 때가 아니라 흔들리는 테스트를 고칠 때라는 신호로 읽습니다.

E2E 를 많이 붙일수록 안전해진다고 보는 경우가 가장 많습니다. 사용자와 가장 가까운 테스트이니 많을수록 좋아 보입니다. 하지만 개수가 늘면 실행 시간과 깨지는 빈도가 같이 늘고, 실패의 대부분이 진짜 버그가 아닌 상태가 두어 달 이어지면 사람들은 빨간불을 보고도 재실행 버튼부터 누릅니다. 그때부터는 테스트가 있어도 없는 것과 같습니다.

E2E 가 통과했으니 품질이 확인됐다고 읽는 것도 같은 문제입니다. 이 테스트가 보는 것은 미리 적어 둔 몇 개의 경로뿐입니다. 테스트가 훑고 지나간 코드의 비율인 테스트 커버리지를 재 보면 E2E 몇십 개가 덮는 범위는 생각보다 좁습니다. 통과한 E2E 는 적어 둔 흐름이 오늘도 된다는 뜻이지, 어제 고친 곳이 안전하다는 뜻은 아닙니다.