본문 바로가기
WEB/일반

[WEB] 테스트 코드 라이브러리 Jest 사용해보기 - 1

by IT황구 2023. 5. 15.
728x90
반응형

 

FE에서 테스트는 참 말이 많은 주제인것 같습니다. E2E, Unit Test를 도입해서 view, logic 을 모두 테스트하고, 커버리지도 100% 달성하겠다! 이런 것은 쉽지 않습니다.

 

Input과 Output이 명확한 데이터를 다루는 영역에서는 테스트를 작성할때 이슈가 많이 없지만, FE는 DOM을 실시간으로 바꾸고 그 화면들을 테스트 하는것은 쉽지 않습니다. 또한 들어가는 노력에 비해서 return이 그렇게 크다고 생각하지 않습니다.

 

테스트를 도입해서 생기는 코드의 견고함과 안정성은 동의하지만, 화면같은 경우 자주 설계같은것이 바뀌게 되는데 그럴때마다 새롭게 TC를 정의하고 확인하는것이 시간 대비 효율이 맞나 싶은 생각이 있습니다.

 

하지만 util함수에는 BE처럼 똑같이 테스트를 할 수 있겠다고 생각을 했습니다.

 

마침 제가 작게 만들었던 라이브러리가 있었고, 팀원분께서 오류를 확인해주시면서 테스트도 추가하면 좋을것 같다는 의견을 주셨습니다. (생각보다 어려워서 아직은 실패했지만.. ㅠㅠ)

 

주말동안 처음 사용해보는 테스트 라이브러리를 어떻게 찾았는지 써보려고 합니다.

 

테스트 라이브러리 선택하기

jest vs mocha

 

위의 링크에서 Mocha, Jest를 추천해주었고 장점에 대해서도 설명해주었습니다.

 

하지만 읽어보면 When to use가 사실상 같은것을 확인할 수 있었습니다.

(이때는 몰랐지만, 막상 유명 라이브러리들에 순위가 낮은 테스팅 라이브러리가 포함된 경우도 좀 있었습니다. 즉, 제가 테스트 하는 유틸정도의 수준은 모든 라이브러리에서 전혀 문제가 없다는걸 알 수 있었습니다)

 

원하는 기능이 있는가?

 

test를 도입해서 Input output의 결과를 확인하는것도 있지만, 비동기 요청같은 것에도 설명이 잘 되어있고 편하게 할 수 있었으면 좋겠다고 생각했습니다. 두 라이브러리 모두 제가 원하는 기능들은 모두 지원을 하고 있었습니다.

 

핵심 Benefit을 보니 mocha는 back-end 라는 키워드가 들어가있는것을 확인할 수 있었고 (FE가 없다는 뜻은 아닙니다), Jest는 FE에 조금 더 많은 키워드들이 있는것을 확인할 수 있었습니다.

 

두 라이브러리 모두 속도나 coverage report 등 필요한 기능들에는 하자가 없는것을 확인할 수 있었습니다.

jest는 Facebook에서 maintain 되기 때문에 조금더 React 친화적일수는 있겠다. 라는 생각을 했습니다.

 

아무것도 모르는 상황에서 두개 다 써 볼수는 없었습니다.

 

생태계의 차이

 

다음에 찾아본것은 생태계의 차이였습니다.

 

jest가 mocha에 비해 훨씬 규모가 큰 것을 확인할 수 있었습니다.

사용하는 사람이 많을수록 문제가 생겼을때 빠르게 해결할 확률이 높습니다.

 

결론적으로 저는 Jest를 먼저 이용해보기로 했습니다.

 

Jest 이용하기

설치하기

jest를 사용하기 위해서 getting started를 보면서 설치를 했습니다.

 

그런데 보통 이런 경우에는 JS를 이용한 경우가 많은데, 이 방법은 편하지만 내가 맞게 값을 넣고 있나? 라는 문제가 있습니다. TS를 쓰면 함수가 어떤 인수를 받고 반환값을 제공하는지 볼 수 있어서 훨씬 편합니다. (docs를 매번 보지 않아도 됩니다)

 

따라서 저는 TS를 이용해서 설치했습니다.


  • npm i -D jest
  • npm install --save-dev babel-jest @babel/core @babel/preset-env
  • npm install --save-dev @babel/preset-typescript
    • TS를 사용하려면 일단 바벨을 설치해야 합니다.
  • npm install --save-dev @jest/globals

 

이후에 babel.config.js 파일을 생성해줍니다. 아래 코드를 붙여넣기 합니다.

module.exports = {
  presets: [
    ["@babel/preset-env", { targets: { node: "current" } }],
    "@babel/preset-typescript",
  ],
};
 

 

npm install --save-dev @jest/globals 이 부분은 짚고 넘어가야 할 것이 있습니다.

일반적으로 typescript의 Type 파일은 @types로 시작하는것을 많이 보실 수 있습니다.

 

DefinitelyTyped에서 지원해주는 그 형태가 맞습니다. 저는 그 방식을 택하지 않고 @jest/globals를 택했습니다.

새로운 수정이 있을경우에 결국 다른사람이 maintain을 해줘야 하는 Def..Types와 달리, @jest는 직접 jest 메인테이너가 관리를 해주기 때문에 조금 더 빠르게 정확한 정보를 받아볼 수 있기 때문입니다.

 

이후 Test 파일을 생성한 후에 npm test 를 해보면 확인할 수 있습니다.

 

이 부분은 공식문서에 잘 나와있으므로 넘어가도록 하겠습니다.

// minut.test.ts

Matcher

  • 테스트 값들을 다양한 방법으로 확인할 수 있는 함수

 

expect를 통해서 실제 어떤 결과가 올지를 넣고, Matcher를 이용해서 값들을 다양한 방법으로 확인할 수 있습니다.

 

위의 코드에서 Matcher는 'toBe', 'toBeGreaterThan' 이 되겠습니다.

그 외의 자료들은 공식문서에 Using Matcher 탭에서 찾아보시거나, type 정의 파일에서 보시면 더 좋을것 같습니다.

 

test vs it

test는 왜 만든거지..

공식문서에 나와있는대로 코드를 만들다보니 한가지 의문이 들었습니다.

 

test()를 통해서 test name과 test function을 제공할 수 있는데, it() 이라는 것도 똑같이 존재하는것을 확인할 수 있었습니다.

 

두개의 차이는 무엇인지도 궁금했습니다.

 

다른 사람들도 해당 내용에 대해서 궁금해 했었습니다.

결론적으로 it, test는 완전히 서로 같은 기능으로 사용할 수 있었습니다. 그렇지만 test name naming rule에서 그 차이가 조금 드러나는것 같았습니다.

 

test name을 정할때 (should ~~동작 when ~~) 처럼 사용하는 컨벤션이 있는데 이럴때 it을 사용하면 가독성이 조금 더 좋아지는것을 알 수 있었습니다.

 

 

 

다른곳은 어떻게 사용할까?

 

제 눈에는 it이 조금 더 나아보였는데, 사람마다 다를 수 있다는건 알고 있습니다.

 

하지만 회사에서 공통적으로 사용하는 컨벤션에 맞춰서 가는것이 사회생활을 위해서 맞지 않나 싶습니다.

 

아래 사진의 Next(vercel), React(Meta) 또한 test대신 it을 사용하는것을 알 수 있었습니다.

 

그 외에도 큰 오픈소스들을 찾아보았지만 모두 it을 사용하고 있었습니다.

 

이쯤 되면 test는 왜 만들었지? 라는 생각이 들었지만 여기서 멈추도록 하겠습니다!

 

 

 

마무리

다음 글에는 네이밍 컨벤션은 어떻게 고민했었는지 (아직 결론은 나지 않았지만), 테스트 코드를 작성할때 어떤것을 고려해야 할지 생각해본것 들에 대해서 적어보겠습니다.

 

클린 코드나 리팩토링2판 같은 책들에서 테스트 코드의 중요성을 많이 말하고, 어떻게 만들지에 대해서 많이 말해줍니다.

 

예전에는 당연한 말만 써 놓았네 라고 생각 했었는데, 제가 직접 만드려고 해보니 이 방법 말고는 어떻게 해? 라는 생각이 들었습니다.

 

아직도 뭘 테스트 해야할지.. 어떻게 짜야할지 고민이 많이 됩니다.

오픈소스들을 찾아보고는 있는데, 제가 원하는 내용을 테스트 하는건 쉽지 않네요.

 

 

이상입니다!

 

 

728x90
반응형