Jest 와 Enzyme 으로 unit test code 짜봤다.

npm, ES6, react, jest, enzyme 을 써서 테스트 코드를 작성했었다.

enzyme 테스트 코드는 꽤나 유용한데, 내가 적기는 귀찮고 아래 링크를 참조하면 좋다.

https://www.zerocho.com/category/React/post/583231469a87ec001834a0ec

react 환경에서는 component 별로 unit test 코드를 작성하면 매우 편하다.

enzyme 에서 shallow를 쓰면, 내부 컴포넌트도 중복 없이 테스트할 수 있어서 그것도 참 편하다.

...코드 안 짜려고 했는데, 조금 짜야겠네.

예를 들면, 아래처럼 wrapper.find() 로 하위 컴포넌트도 가져올 수 있다.

(참고로 돌아가는지는 안해봤다. 혹시라도 복붙하지 마시길;; )

shallow 대신 mount를 쓰면, CommentListItem 가 렌더링 된 상태이기 때문에, 

CommentListItem 같은 하위 컴포넌트가 잘 렌더링 되었는지도 확인할 수 있다.

이걸 실전에서 Unit Test 로 작성해서 써보니 확실히 좋은 점들이 많았는데,

불편한 점도 있었다는 것이 이 포스트의 주제다.

좋은 연장도 드는 사람에 따라서 안 좋아질 수도 있다(?)....일 수도 있지만

내가 unit test code 작성이 서툴러서 좋은 참고가 되지 못 할 수도 있으니 그냥 넘어가길 바라며(...)

좋은 점은 갑자기 중간에 수정사항이 들어와서 구조를 변경했을 때 이미 작성한 코드에 side effect 가 예상되는 상황이었다.

평소 같으면 일일이 눌러가며 side effect를 확인해야겠지.

하지만 npm run test 만 해주면 왠만한 side effect는 검출이 되었다. 

만들어야 하는 컴포넌트 종류가 많아지면 많아질 수록 유용했다. 

물론, 요구사항 마다 컴포넌트가 잘 렌더링 되는지 전부 unit test를 짜는 것이 쉬운 일은 아니었다.

매우 빡세고 짜야할 코드의 양 자체가 굉장히 많아졌다.

덕분에 요구사항을 꼼꼼히 확인할 수 있긴 했다.

...뭐 이런건 unit test code 의 장점 그 자체겠지만,

그래도 jest, enzyme 조합이 컴포넌트 단위로 유닛 테스트 코드를 짜는 것을 편하게 해준다고 생각했다.

쓰면서 불편했던 것은, 한 컴포넌트에도 요구사항이 여러 개 들어올 수 있다는 것이었다.

위의 코드 처럼 댓글이 10개 나와야 하는 상황만 있는 것은 아니니까.

댓글이 없는 경우에는 보여줘야 하는 화면이 다르고 

댓글이 16개이면 끝에 6개만 나오는 건 어떻게 테스트 할 것인지도 생각해야 했다.

댓글 안에 text만 들어있는 것이 아닌 경우도 있고, 

모바일/PC 인지에 따라서도 보여줘야 하는 갯수가 달라지기도 했다.

이렇게 되면 요구사항 자체가 CommentList 라는 컴포넌트 하나에 굉장히 많이 걸려있게 되는데,

자연스럽게(?) CommentList 가 받아야 하는 props 가 많아진다.

...그러면 저 요구사항 대로 만든 모든 테스트 코드에서 <CommentList> 에 props 를 모두...하나 하나...넣어주는 작업을 해야하는건가...? =_=...

뭐 'IDE에서 replace 해서 쓰면 되지!' 같은 순진한 생각으로 덤벼들게 아닌게 테스트 코드 마다 props 에 넣어줘야 하는 것들이 다 달라지게 된다.

예를 들어 true/false 만 들어가는 props를 하나 만들어도 테스트할 경우가 두 가지가 된다.

여기서 true/false 가 들어가는 props를 하나 더 추가하면 경우의 수가 2^2 = 4 가 된다.

<CommentList> 의 테스트 코드를 4벌을 만들어야 하니 aProps = true / false, bProps = true / false 

이렇게 IDE의 replace 한 번에는 못하는 props 넣는 작업이 들어가고,

물론 저 4벌 모두 보여줘야 하는 expect() 부분이 달라질테니 expect() 안에서 또 제대로 렌더링 되는지 코드를 또 짜야한다.

말로만 해서 그런데 저 4벌의 expect() 안에서는 aProps 가 두 번 true 가 되니 아주 고치기 애매하게 중복이 발생한다.

물론 redux 써서 action 붙이고...해서 props 없이 할 수 있어도 

컴포넌트 내에 여러 가지 상황이 존재하게 되고 이걸 모두 test 해야하는 건 변하지 않는 일이었다.

요구사항이 늘어날수록 개발자의 작업량도 많아질뿐만 아니라 

테스트 코드 내에서의 중복이 많이 발생하여 테스트 코드 자체를 나중에 수정하기가 굉장히 어려워졌다.

그리고 난 아직 이 해결책을 모르겠다(...) 누가 알려주거나 enzyme 에 뭔가 기능을 넣어줘...

그리고... react 에서 ref를 쓰는 경우가 있는데, 

내 경우는 ref 를 쓴다면 컴포넌트 렌딩 후에 컴포넌트의 style 을 바꿔줘야 하는 경우였다.

...이거 어떻게 테스트...? 이벤트라도 발생하면 simulate() 라도 해보겠는데...

단순히 내가 docs에 나와있는 걸 못 쓰고 있는지도 모르지만,

render() 를 쓰면 한 번 render하고 그 이후에 반영되는 style은 잘 테스트가 안 되었다.

사실 나는 이 테스트가 가장 중요했고, 눈에 너무 적나라하게 보이는 경우라서 꼭 테스트 코드를 만들고 싶었는데,

아쉽게도 작성하지 못했다.

그리고 난 그 부분이 수정사항이 들어오면 side effect이 발생할까봐 살짝 조심스럽게 되었다.

기왕 enzyme 이 react 에 적합하다면 ref까지 지원해줬으면 좋겠는데, 조금 아쉽기도 하지만...

react 자체가 ref 를 지양하는 것 같으니 어쩔 수 없는지도...

아니 그냥 내가 docs 에서 못 찾은 거면 좋겠다(...)

뭔가 더 불편한게 있었던 것 같은데 당장 생각나는 건 이 정도 이려나.

혹시라도 누군가 해결책을 갖고 계신 분이 보시면 덧글 달아주셨으면 좋겠고,

쓸 생각 있으신 분께 좋은 참고...가 되려나 안되려나(...)

불편하다고 생각은 했는데 이렇게라도 쓰니 속 시원해서 그건 좋네.