프론트엔드 테스트 종류 4가지(단위/통합/E2E/시각적 회귀)가 각각 어떤 것인지, 그리고 어떨 때 이걸 선택하는지 알게 되었다.

• 함수가 단위 테스트하기 어렵다면 설계 자체를 의심할 수 있다. 테스트하기 쉬운가? = 이 함수가 순수하게 잘 작성되었는가.
• 통합 테스트에서 어떤 동작을 하거나 요소를 찾을 때는 실제 유저가 읽는 방식으로 해야 한다. (클래스나 태그 id 등으로 찾는 것이 아니라)

"구현 세부사항"을 보지 않는다!! 테스트에 들어가야 하는 건 "이걸 바꿨을 때, 사용자가 알게 되나?"다. 내부 변수 이름이 뭐여야 한다는 식의 세부사항은 테스트로서 큰 가치가 없다. 그래서 isLoading 값이 true인지를 보기보다, 불러오는 동안 제출 버튼이 안 눌린다처럼 사용자가 겪을 수 있는 동작을 테스트한다.

기능을 다 만들고 나서 테스트를 작성하면 지금 구현된 대로 그대로 옮겨 적게 된다. 구현을 망가뜨렸을 때 테스트가 정상적으로 실패하면 조금 더 의미가 있을 수 있다.

AI에게 넘길 게 있고 사람이 봐야 할 부분이 있다. 어떤 테스트를 할지, 어디까지 검증할지, 어떤 테스트로 검증할지, 또 테스트가 실패했을 때 테스트가 문제인지 구현이 문제인지는 사람이 설계해줘야 한다. 그 외에 단순 작성 부분은 AI에게 넘긴다. AI한테 그냥 해달라고 하면 조용히 통과만 되는 테스트 코드를 만들기도 한다.

발제에서 E2E 테스트를 할 때 백엔드는 네트워크를 모킹하고 스모크 테스트 몇 개만 남겨둔다고 적혀 있었다. 이번에 해보려고 했는데 내 코드에서는 상대 경로로 Next.js API Route를 호출하다 보니 모킹이 어려웠다.

사실상 지금 구조도 모킹의 일환이라고 보고 별도로 처리하진 않았다. 하지만 실제 서버와 연결되는 상황이라고 하면 MSW로 모킹하는 식으로 바꿔볼 수 있을 것 같다.

구현 중에 Vitest가 모두 jsdom 위에서 도는 걸 발견했다. 사실 테스트 코드는 전반적으로 AI가 해줘서 믿고 있었는데 이런 부분에서 의심을 해야 하는구나 깨달았다. 그리고 역시 아는 게 있어야 의심을 할 수 있다고도 느꼈다.

암튼 그래서 환경 세팅에 걸리는 시간을 보니, jsdom이 브라우저나 로컬 스토리지 같은 걸 모두 불러와야 하다 보니 시간이 걸렸다. 지금은 테스트가 많지 않아서 8초 수준이지만 더 많아졌으면 오래 걸려 병목이 되었을 수도 있다.

그래서 test.projects를 통해 jsdom, node 환경을 파일 확장자로 분리하도록 했다. 파일마다 분리하는 방식도 고민해봤는데, 유용할 수는 있겠지만 일일이 지정한다는 게 누락이 생길 수도 있고 각 파일 상단에 뭐라고 적혀 있는지 보기 전에는 알 수 없기 때문에 projects로 파악하기 쉽게 하는 게 맞다고 생각했다.

그리고 사실 아직도 고민인 부분은, 파일 확장자뿐만 아니라 그냥 파일 이름에 .node.ts / .jsdom.tsx 이런 식으로 명확한 단어를 넣어서 구분하게 하는 것이 예외도 안 생기고 깔끔하려나 싶기도 하고, 근데 또 매번 저걸 고민해서 넣어주기는 좀 귀찮아서 확장자로 분리하고 예외만 적어주면 되지 않나 싶기도 해서 정답은 모르겠다.

상품 목록에서 조건이 변경되고 목록이 제대로 변경되는지에 대해서는 처음에 E2E가 적절하지 않을까 생각했는데, 통합으로도 충분하다고 생각을 바꿨다.

이 부분도 세세하게 쪼개면 봐야 할 부분이 굉장히 많은데 이걸 E2E로 모두 보는 게 낭비라고 생각이 들기도 했고, 통합 테스트로 모두 연결하고 nuqs나 네트워크 모킹도 가능해서 충분히 검토가 된다고 봤다. 대신 E2E에서 실제로 이 URL이 적용이 되는지 본다면 검증이 될 거라고 생각했다.

테스트 코드를 만들면서 "직전 목록 조회 결과가 있다면 조건 변경 시 조회가 실패하더라도 직전 목록을 보여주고 재시도는 상단 배너로 출력한다"라는 테스트 코드를 짜다가 오류를 발견했다. (7주차에 피드백 받았던 내용인데 일단 넘어가자 생각했던 부분이다..) 테스트 코드를 짜니 빨간 불이 나왔고 그에 맞게 구현도 수정했다.

이걸 보면서, 지난주 과제를 할 때 테스트 코드를 AI에게 전부 위임하는 것이 아니라 내가 좀 더 생각해서 이 케이스를 추가했다면 버그가 안 생겼을 텐데 하는 아쉬움도 있었다.

• 이번 주는 면접 준비와 체력 이슈로 발제 내용을 꼼꼼하게 복습하지 못해서 아쉬움이 많이 남는다. 발제 내용에 있는 부분을 조금 더 깊이 살펴보면 좋을 것 같다.
• 4주차에 작성한 Select, Dialog에 대해 스토리북으로 시각적 회귀 테스트를 해보면 좋을 것 같다는 생각을 했다. 이런 툴을 쓸 생각은 못 해서 데모 페이지 정도를 만들었는데, 실제 디자인 시스템이라고 생각하면 스토리북으로 배포해서 디자이너도 같이 볼 수 있게 했을 것 같다.