지난 편에서 8개 태스크를 전부 구현하고, 태스크마다 리뷰를 붙이고, 마지막에 전체 브랜치 리뷰까지 마쳤다. 테스트는 90개 넘게 전부 초록불이었다. 이 정도면 실전에 붙여도 되겠다 싶어서, 실제 키워드 몇 개로 진짜 수집을 처음 돌려봤다.
에러는 안 났다. 대신 결과가 이상했다.
정규식이 실패해서 이름이 전부 비어 있었다
한쪽 플랫폼에서 수집한 앱들의 이름 칸이 전부 빈 문자열이었다. 세 개를 수집했는데 세 개 다 그랬다. 저장된 원본 페이지를 열어서 직접 찾아보니 원인은 허무할 정도로 단순했다. 앱 이름을 뽑는 정규식이 `
이 코드를 검증하던 테스트 픽스처를 다시 열어보니, 손으로 만든 그
HTML에는 <title>이 속성 없이 깨끗하게 들어가 있었다. 페이지 구조를
“이 정도면 맞겠지” 하고 손으로 재현했는데, 정작 실제 페이지가 갖고 있는
그 속성 하나를 재현하지 않았던 것이다. 테스트는 자기가 만든 가짜
페이지를 기준으로는 완벽하게 맞았다. 그 가짜 페이지가 진짜와 달랐을
뿐이다.
다른 플랫폼에서도 정규식 기준 문자열이 틀렸다
다른 플랫폼에서는 회사의 한국 여부를 판정하는 데 쓰는 정보(사업자
등록번호, 전화번호 같은 것)를 뽑아오는 코드가 있었다. 이걸 특정 구역
안에서만 찾도록 일부러 경계를 그어뒀다 — 페이지 전체를 뒤지다 보면
전혀 상관없는 곳에 우연히 비슷한 문자열이 있어서 잘못 걸릴 수 있기
때문이다. 그 경계를 찾는 기준으로 class="information이라는 문자열을
썼다.
실제로 저장된 페이지를 열어서 확인해보니, 그 구역은 class가 아니라
id="information"으로 식별되고 있었고, class 값은 완전히 다른
이름이었다. 기준 문자열이 실제 페이지 어디에도 없으니, 이 코드는
“찾을 수 없음” 처리로 조용히 빠져나갔다. 예외도 안 나고, 카운터도
안 움직이고, 그냥 판정에 필요한 신호가 하나도 없는 것처럼 취급됐다.
결과적으로 그 플랫폼에서 수집한 회사 전부가 한국 회사인지 아닌지
“알 수 없음”으로 떨어지고 있었다 — 진짜 정보는 페이지 안에 멀쩡히
있었는데도.
왜 테스트가 이걸 못 잡았나
두 경우 다 테스트 자체는 논리적으로 틀리지 않았다. 문제는 테스트가 검증하는 대상이 “내가 상상한 페이지 구조”였지, “실제로 그 서비스가 지금 내려주는 페이지 구조”가 아니었다는 데 있었다. 리뷰 단계에서 이 픽스처들을 다시 볼 때도, 규칙 하나(닫는 태그 사이에 줄바꿈이 있으면 정규식이 깨진다)는 미리 알고 있어서 그건 잡았다. 그런데 “속성이 하나 더 붙어 있는가”, “구역을 식별하는 속성 이름 자체가 맞는가”처럼, 애초에 확인 목록에 없던 종류의 어긋남은 아무도 의심하지 않았다.
고친 방법도 단순했다. 이름을 뽑는 정규식에 속성이 있든 없든 다 받도록
한 글자를 더 넣었고, 구역 경계는 class 대신 실제로 확인한
id="information"으로 바꿨다. 그리고 테스트 픽스처도 손으로 상상한
버전이 아니라, 방금 실제로 받아온 페이지에서 그 구역을 그대로 잘라내서
다시 만들었다. 이번엔 픽스처가 진짜를 베낀 것이니, 다음에 이 구조가
또 바뀌면 최소한 그때는 테스트가 먼저 알려줄 것이다.
남는 생각
리뷰 여러 번, 테스트 90여 개, 전부 통과. 그런데도 실제 페이지에 처음 붙이자마자 핵심 데이터 두 종류가 통째로 비어 나왔다. 손으로 만든 테스트 데이터는 아무리 정성 들여 만들어도 “내가 맞다고 믿는 모양”일 뿐이다. 진짜로 맞는지는 실제 응답을 한 번 받아서 눈으로 비교해보기 전까지는 아무도 모른다. 이번 세션에서 이 실수를 두 번 반복하고 나서야, “검증이 끝났다”와 “실물을 확인했다”는 서로 다른 문장이라는 걸 다시 새겼다.