Jest, Jasmine의 matchers 메소드 비교, 대조

이제는 테스트를 해야만 한다.

 

처음에, 그때는 Angular.js였는데, 웹 프레임워크를 공부하던 시절부터 테스트 환경 설정은 프레임워크 환경 설정이 기술된 챕터 2나 그 다음 챕터 3 정도에 있는 주제였습니다. 그렇지만 정말로 어플리케이션을 만들고 운영하기 전까지 테스트가 도대체 어디서 필요한지를 스스로 아는 것은 어렵지요. (어렵지 않나요?)

 

그래서 Jest를 쓰기로 했습니다. "그래서" 부분은 생략된 챕터가 많은데, 아무튼 현재는 Vue가 주사용 프레임워크이고, vue-jest가 사용하기 편리하고, 무엇보다 커뮤니티가 활발하고, 그만큼 레퍼런스가 많았습니다. 테스트 코어와, 매처, 러너가 한 번에 설치되는 이점이 물론 제 1의 근거였습니다.

 

Jest는 브라우저 환경의 스크립트를 실행할 때에 jsdom으로 가상화된 브라우저 환경을 구축합니다. 몇몇, 아니다, 상당히 많은 브라우저 제공 API가 undefined 되어있고, Jest가 제공하는 환상적인 automocking(뭐라고 하면 좋을가..?!) 기능과 함께 어우러져 다른 프레임워크 대비 굉장히 빠르게 테스트를 수행할 수 있도록 하는 데에 기여합니다. 다만 문제는 여기서부터 시작합니다. 종종 브라우저의 API를 헤비하게 요구하는 함수들이 있을 수도 있는데요, 이를테면 얼마 전에 정리한 적이 있던 downscaleImage.js가 그러한 예가 되겠죠. jsdom은 대부분의 CanvasRenderingContext2D의 메소드를 호출하지 못합니다. URL#createObjectURL도 마찬가지입니다.

 

결국 브라우저에서 직접 테스트를 수행하는 테스트 러너 Karma를 사용하기로 했습니다. 또한 테스트 프레임워크로서 Jasmine을 택했는데, 사실 Jest는 Jasmine의 포크이기 때문입니다. (jest-jasmine2 패키지의 라이센스 주석에서 확인할 수 있습니다.) 음, 아무래도 테스트 프레임워크를 이원화하는 것은 마음에 들지 않는데, 어쩔 수 없는 것도 같습니다. 원래 Jest가 바라보고 있는 곳이 그러하니까요.

 

"describe"로 시작하는 suite 묶음은 같습니다. Jest는 spec 묶음으로 "test", "it" 모두 사용이 가능하지만, Jasmine은 "it" 함수만이 제공됩니다. matchers는 모두 "expect"로 시작하나, 그 matchers 멤버의 목록은 다소 다릅니다. 공식 API 문서의 HTML을 파싱하여 정리해보았습니다.

 

https://sungchuni.github.io/parse-matchers/

https://sungchuni.github.io/parse-matchers/

소스 코드는 https://gist.github.com/sungchuni/e3ab828f67e2bc0d19553111fcd1b4ee에 있습니다.

 

toBe나 toBeGreaterThan, toEqual 같은 메소드는 둘 다 가지고 있습니다. 자주 사용되는 toBeDefined, toContain이나 toThrow도 모두 있습니다. Jest의 toHaveLenth는 Jasmine에서 toHaveSize가 됩니다. Jasmine은 toBeTrue나 toBeFalse가 있지만 Jest는 없습니다. (그냥 toBe(true)하면 되잖아. 지만 toBeNaN도 있고 toBeNull도 있기도 하고,) 비동기 함수에 대해 Jest는 resolves 프로퍼티를 체이닝하여 다시 동기 함수를 테스트하듯이 사용하지만, Jasmine은 expect가 아닌 expectAsync를 호출하여 matcher를 호출합니다. 공식 문서에는 비동기 matcher 섹션이 따로 있으나 여기엔 같이 정리해두었습니다. 스냅샷 테스팅은 Jest만의 유니크한 무기인데(그리고 서버 스크립트 환경에서 동작하니까) 그래서 toMatchSnapshot 같은 것은 Jasmine에게 없습니다.

 

@types/jest나 @types/jasmine을 활용하거나, 혹은 직접 라이브러리를 임포트해서 조금 더 지속성이 있는 메소드 비교 앱을 만들 수도 있겠습니다.

 

CI/CD 프로세스에서 Jest는 기존의 환경을 그대로 사용할 수 있겠지만(린트나, 빌드 등등의 처리를 이미 하고 있었다면), Karma 테스트를 위해서는 해당 서버에 적절한 브라우저가 설치되어 있어야 하겠습니다. 음, 아무래도 테스트 프레임워크를 이원화하는 것은 마음에 들지 않는데, 않는군요.