이번 주에는 CLI 도구에 테스트를 추가하기로 되어 있었습니다. 지금까지 가장 실망스러운 일입니다.

내가 Jest를 선택한 이유

저는 TDD(Test Driven Development)의 열렬한 지지자입니다. 거의 모든 부분의 코드를 테스트해야 합니다. 협동조합을 하는 동안 저는 PR을 위한 작문 시험에 절반 이상의 시간을 보냈습니다. 그 경험이 테스트의 필요성을 이해하는 데 큰 도움이 되었다고 생각합니다. JS와 Ruby의 테스트 프레임워크가 얼마나 유사한지 보고 놀랐습니다. 나는 협동 작업 중에 사용한 RSpec과 매우 유사한 Jest를 사용했습니다. http 요청을 조롱하기 위해 VCR이라는 것과 유사한 Nock을 사용했습니다.

내가 직면한 문제(많음)

제가 직면한 가장 큰 문제는 CommonJS 대신 ESM을 사용했다는 것입니다. 내 인생을 훨씬 더 힘들게 만들었습니다. 첫 번째 문제는 jest.mock이 작동하지 않는다는 것입니다. 몇 가지 연구 끝에 ESM에서 조롱하는 방법이 다르다는 것을 깨달았습니다. 불행히도 문서를 따른 후에도 제대로 작동하지 못했습니다. 그래서 jest.spyOn을 해야 했습니다. 내가 직면한 두 번째 문제는 execa가 index.test.js의 child_process에서 실행되기 때문에 실행되지만 적용 범위 보고서에는 영향을 미치지 않는다는 것입니다. 그래서 테스트를 다시 작성하려면 jest.spyOn을 사용해야 했습니다. 또한 jest에 전달하는 플래그를 사용하지 않도록 index.js를 리팩터링해야 했습니다. 내가 직면한 또 다른 작은 문제는 jest -c jest.config.mjs 대신 node --experimental-vm-modules --no-warnings node_modules/jest/bin/jest.js -c jest.config.mjs를 사용하는 것이었습니다. ESM을 사용합니다. 또한 간단한 jest.spyOn이 충분히 철저하게 테스트하지 않았기 때문에 FilepathResolver.test.js를 테스트하기 위해 파일 시스템을 복제하기 위해 mock-fs를 사용해야 했습니다. ESM을 사용하는 것만으로도 얼마나 많은 장애물이 발생하는지 놀랐습니다. 이는 JS가 얼마나 엉망인지를 반영합니다.

수많은 시행착오 끝에 꽤 좋은 보도를 얻었습니다.