React Unit Test — react-testing-library, 너를 알아가는 시간

Juyeon Ma
Juyeon Ma
Nov 4 · 5 min read

부제: Enzyme을 버리고 react-testing-library를 써보았다.

react-testing-library 사용 소감을 적음.

Javascript의 unit test에 늘 사용했던 mocha, chai, sinon 삼형제(귀찮은것들..)를 jest의 등장과 함께 빠르게 버리고 갈아탔었음에도, Enzyme의 자리는 여전히 바꾸지 않았었다.

Enzyme은 테스트 과정에서 클래스 컴포넌트 인스턴스에 접근해서 이것저것 트리거하고 검사하기에는 무척 다루기 편했다. 그런데… hook 등장 이후로 클래스형 컴포넌트를 전보다 훨씬 적게 사용하게 되었고. 자연스레 이전보다 함수형 컴포넌트 (hook) 녀석들을 테스트해야 할 일이 많아졌다. 쓰던 대로 Enzyme을 어떻게든 써보려 했는데, 제약이 있었고, 해줘야 할 것도 많고, 왜인지 잘 돌아가지 않는 등 불편. 그래서 찾아보니 괜찮은 새거놈 하나가 등장해 있다. 이름하야 react-testing-library. 그래서 기대감을 갖고 또 써봤지

물론 두 녀석은 각자의 장단점을 갖고 있는듯 하지만, 내가 느낀 가장 큰 차이점은 녀석들이 추구하는 테스트코드의 철학스멜(?)이었다. 그게 달라보였다.

물론 내 느낌이지만 특징적인 느낌을 좀 부풀려 표현해 보자면


Enzyme:

그 컴포넌트에게 이 값을 전달하면 prop이랑 state가 그 값이 되야해!
그 이벤트를 트리거하면 너의 둘째 div의 텍스트 값은 그것이 될거야!

react-testing-library:

그래서 화면에 뭐가 보이는데?
그래서 걔가 출력한 값이 뭔데?


구경꾼 1인칭 시점, 이녀석의 느낌.

  1. Facebook 에서 테스트에 이녀석을 쓰길 권장한단다. 마치 사대주의에 편안히 굴복하고 싶은 기분이다.
  2. document 가 간단하다. 복잡하지 않은 가벼운 느낌
  3. 쿼리 라는 것으로 타겟엘리먼트에 접근(을 권장). 근데 이 쿼리가 셀렉터 쓰듯 다양하지 않다. 그저 텍스트로 찾고 라벨로 찾고.. 단순단순. 난 꼭 필요한 볼놈만 본다 느낌이 들었음.
  4. 그 말은 곧 BDD 철학으로 짜라고 말하고있는 듯한 API. 일어나는 연쇄 과정에 신경쓰지 않는, 내부로직을 신나게 뜯어 고쳐도 결과가 같음을 추구. = 리팩토링 해도 테스트 안 깨진다

조금 더 써보고 느낀점

  • 테스트가 실제 DOM 에서 동작한다. Enzyme은 instance를 이용한 테스트가 많았는데 이집 녀석은 짜다 보니 굉장히 DOM 중심의 테스트
  • 게다가 뭐랄까.. 테스트 돌아가는 내부사정은 그집이나 이집이나 비슷한데, 사용 방법에서 느낌이 좀 달라서 적응하는데 예상보다 시간이 살짝 걸림. 검사하고자 하는 엘리먼트를 텍스트로 찾고 라벨로 찾고 하는데,(이게 엔자임이랑 또 느낌이 되게 다르지) 이 과정에서 사용자중심(Behavior) 사고를 해야 했다.
  • 또한. 엔자임 써본 사람이라면 알겠지만 그 집엔 기능이 차암 많다. mount, shallow, render 컴포넌트 띄우는 방법만 해도 세가지. 얘도 그렇지 않을라나 생각했다가 도리어 헤맴. render 하나만 쓰면 된다. 이 녀석의 의중을 빠르게 파악하지 못한 것이 함정이 되었다.
  • 그래서 기존의 엔자임의 shallow 같은 걸 하려면, 직접 상황을 구성해주어야 한다. 그러니깐, child component, lifecycle method 등을 직접 mocking해서.
  • 어쨌거나 Enzyme 안 써도 되겠다. 대체 가능하겠단 생각은 든다. 내 의도와 다르게 또는 이상하게 useEffect가 호출 안된다거나 그런 일은 없다.
  • 다만 말했듯 패러다임이 꽤나 달라서, 이게 과연 유닛테스트가 맞는가 혼란스러웠다. 녀석의 의도대로 테스트를 작성하다 보면 통합테스트처럼 되어버리기 쉽다. 엔자임처럼 컴포넌트 모델 자체의 동작을 단위별로 테스트하는 게 유닛테스트 아니었나? 내가 생각하는 테스트코드의 개념이 무엇인지에 따라, 그리고 제품에 필요한 테스트의 형태가 어떠한지에 따라 어떤 라이브러리를 쓸 지 결정해야 할 것 같다.
  • 아, 전제가 빠졌다. 물론 기본적으로 테스트 프레임워크나 라이브러리에는 익숙해야 한다. 테스트 삼형제 test runner + assertion (matchers) + mocking 각각이 어떤 역할을 하는지, 어떤 방식으로 돌아가는지 바탕지식으로 깔려 있어야 사용 가능. (우리는 jest를 사용한다.)
  • E2E 테스트의 영역은 커버되지 않는다. 당연히 cypress든 nightwatch든 e2e 테스트는 별도로 필요하다.

조금 더 생각해보고 얻은 깨달음

  • 내가 코드를 잘 짜면 테스트짜는 건 어렵지 않다
  • TDD (또는 TTDD, Test Thinking Driven Development, 구냥내가만들어본말..) 를 하자

마무리

테스트 코드의 세계 재미쪄

안써본 리액트 테스트 라이브러리 직접 써보긴 귀찮고 어떤지 궁금은 한 그런 분들에게 도움이 되기를(?)

예제 코드와 사용 방법은 이제 막 코드를 열심히 짜기 시작했으므로, 코드 작성하면서 차차 다음 블로그에 작성해 보기로 !

도움 받은 사이트

테스팅라이브러리 메인 페이지의 문구가 참 좋다.
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade