검사는 통과하는데 실제로는 깨져 있을 때

jsdom 테스트는 전부 통과하는데 브라우저에서 레이아웃이 깨져 있습니다

무엇이 보이는가. 컴포넌트 테스트가 전부 초록입니다. 그런데 실제 브라우저에서 열어 보면 레이아웃이 다릅니다.

왜 그런가. jsdom은 레이아웃을 계산하지 않습니다. getBoundingClientRect()를 호출해도 실제 CSS 레이아웃 엔진이 값을 계산해 주지 않습니다. “이 요소의 폭이 그대로다” 같은 assertion은 jsdom에서 원리적으로 아무것도 검증하지 못합니다.

어떻게 확인하는가. 문제의 assertion을 지우고도 테스트가 통과하는지 보십시오. 통과한다면 그 assertion은 애초에 아무것도 잠그지 않고 있었던 것입니다.

어떻게 고치는가. 픽셀 값 자체 대신 픽셀을 결정하는 조건을 잠그십시오. 형제 관계, 자식 순서, 어떤 클래스가 어떤 상태에서 붙는지가 여기 해당합니다. 실제 렌더 결과는 브라우저에서 실측하는 별도 하네스로 옮깁니다. 잠근 것과 잠그지 못한 것을 테스트 이름과 주석에 정직하게 남기십시오. 메커니즘은 Test를 참고하십시오.

테스트가 구현하기 전부터 통과하고 있었습니다

무엇이 보이는가. 기능을 구현하기도 전에 관련 테스트를 돌려 보면 이미 통과합니다.

왜 그런가. 테스트가 컴포넌트가 실제로는 렌더하지 않는 요소를 대상으로 assert하고 있습니다. 존재하지 않는 요소에 대한 not.toBeInTheDocument() 류의 assertion이나, 셀렉터가 잘못돼 아무것도 못 찾은 채로 조용히 통과하는 경우가 여기 해당합니다.

어떻게 확인하는가. 구현을 잠깐 되돌리거나 아직 안 된 상태에서 테스트를 돌려 보십시오. 이 시점에 통과하면 그 테스트는 원하는 것을 검증하고 있지 않습니다.

어떻게 고치는가. 테스트를 작성한 직후, 구현 이전 상태에서 반드시 한 번 실패시켜 보십시오. 실패를 보지 않은 테스트는 무엇을 잠그는지 아직 증명되지 않은 것입니다.

새로 추가한 검사가 아무것도 안 잡고 통과합니다

무엇이 보이는가. 새 lint 규칙이나 감사(audit) 스크립트를 추가했는데, 대상이 되어야 할 위반 사례가 있는 상태에서도 초록입니다.

왜 그런가. 패턴 매칭 하나가 어긋나면 검사는 아무것도 매치하지 못한 채 조용히 전부 통과합니다. 초록이 “위반이 없어서”가 아니라 “검사가 애초에 아무것도 안 봐서”인 경우입니다.

어떻게 확인하는가. 새 게이트를 추가한 직후, 고치기 전에 먼저 exit 1이 나오는지 확인하십시오. 의도적으로 위반 사례를 만들어 검사에 걸리는지 보는 것도 같은 방법입니다.

어떻게 고치는가. 순서를 지키십시오. 검사 추가, 실패 확인, 수정, 초록 확인 순입니다. 실패를 한 번도 보지 못한 게이트는 신뢰할 수 없습니다. 메커니즘은 Lint를 참고하십시오.

exit code가 0인데 실제로는 실패했습니다

무엇이 보이는가. 셸 체인(&&)에 넣어 둔 명령이 성공한 것처럼 넘어가는데, 결과물이 만들어지지 않았거나 원하는 상태가 되지 않았습니다.

왜 그런가. 모든 CLI 도구가 실패 시 0이 아닌 종료 코드를 보장하지는 않습니다. 조건에 따라 아무 작업도 하지 않고 exit 0으로 끝나는 도구가 실재합니다. 이런 도구를 && 체인에 넣으면 실패를 알아챌 방법이 없습니다.

어떻게 확인하는가. 명령 실행 후 결과물(파일 생성 여부, 크기, 내용)을 별도로 확인하십시오. 종료 코드만으로 판단하지 않습니다.

어떻게 고치는가. 종료 코드를 계약으로 신뢰하기 전에 그 도구가 실패 조건에서 실제로 비정상 종료하는지 한 번 확인하십시오. 신뢰할 수 없다면 결과물 존재 여부를 직접 검사하는 단계를 뒤에 추가하십시오.