민섭 trouble‐shooting‐2
에러 해결하면서 겪은 팁들 공유합니다.
- ts는 tsx가 아닐 때 사용한다고 합니다... test도 적용이 되는 줄 몰랐네요 😢😢
react query를 사용하는 경우에서 주의해야합니다.
test환경에서도 provider 설정이 필요합니다. 저희 main.tsx 보면 queryProvider이 있을거에요!!
해당 provider을 testing 환경에서도 적용해줘야 합니다.
다음과 같이 createWrapper라는 custom provider를 만드는 함수를 선언했습니다. export 해서 다 같이 쓰면 좋겠네요 :D
저의 로직은 버튼을 클릭하면 mutation함수가 돌아가고 setLike함수가 실행되면서 like 숫자를 조정하는데요,
여기서 중요한 점이 있습니다.
wrapper을 변수로 받아와서 render()안에 넣어주었는데요, 이 컴포넌트가 실행될 provider을 제공해주는 개념입니다. 즉 리엑트 쿼리를 사용한 모든 컴포넌트에는 저 provider을 넣어주셔야 해요!!
이렇게 render 함수만 잘 정의하면 mutation을 사용하는 쿼리에서는 잘 작동합니다.
저의 heart 버튼은 초기값은 false로 isWish값이 false일 때 생각하시면 됩니다.
유저가 저 하트 버튼을 눌렀을 때, 하트 버튼이 잘 올라가고 내려가는 지 테스트해야합니다 (이게 컴포넌트에서 가장 중요한 기능이에요!!)
그렇다면 중요한 것은 유저가 클릭하는 기능이 추가되어야 합니다.
이 라이브러리가 유저의 행동을 정의합니다.
공식 문서를 보면 총 3가지의 유저 액션이 있네요.
click, hover, tab의 경우에만 체크하면 될 것 같습니다.
사용법은 간단합니다!!
user라는 객체를 만듭니다.
유저가 클릭할 객체를 지정해주고 (바닐라 자바스크립트처럼 document로 가져와도 됩니다!!)
user라는 객체에 click 메소드를 넣어주면 됩니다!! 정말 간단해요
이후
모든 액션이 비동기가 끝나면 실행되게하는 waitFor 함수를 사용해서 체크하면 됩니다.
jest가 공식 문서에 잘 나와있기는 합니다!! 한번 쭉 읽어보시는 것을 추천 드립니다.
하면서 느낀 건데 testing 순서를 짜는데 있어서 GWT패턴이 있더라고요.
해당 패턴을 적용한 결과입니다.
-
given은 주어진 조건입니다!! 말 그대로 테스트해볼 조건이에요. 이건 마음대로 설정하시면 될 것 같습니다.
-
when은 어떠한 액션이 시작되거나 어떠한 이벤트가 발생했을 때 입니다. 저희가 테스트할 딱 그 시점일 것 같습니다.
-
then은 말 그대로 그다음 나온 결과입니다. 저희가 expect로 test할 로직들입니다.
describe는 저희의 큰 함수 전체라고 볼 수 있습니다!!
테스트 꾸러미라고 생각하시면 돼요!!
보면 describe가 모든 test들을 안고 있습니다 :0
test 또는 it으로 테스트 객체를 만들 수 있습니다.
이 친구도 작은 함수라고 생각하시면 될 것 같습니다.
test에는 작은 기능들이 들어갑니다.
저의 test 코드에서도 보면
여러 조건들에 따른 test들이 있습니다. (멘토링 때 test구분을 여쭤봐도 좋을 것 같네요 :ㅇ)
중요합니다!! expect는 최종으로 보여줄 결과물입니다.
테스트 코드는 내부 구현보다는 실행 결과에 집중하는 것이 리팩토링 내성을 높일 수 있다합니다.
저의 경우 버튼을 눌렀을 때 하나 감소하는 것이 올바른 결과물이고 이를 expect함수 안에 넣었습니다.
expect는 무조건 최종 결과물이어야 합니다!!
객체를 가져오는데 id값을 다 주기에는 피곤합니다...
그래서 screen이라는 것을 사용할 수 있습니다.
screen은 단순하게 화면에 보이는 것입니다.
screen.getByText는 말 그대로 screen에서 해당 텍스트를 가진 객체를 찾는 것입니다.
저기서는 "5"를 가진 객체가 되겠네요!!
만약 screen을 안쓴다면
JS와 똑같이 dom element를 가져오는 것처럼 하면 됩니다!!
편하신 방법으로 가져와도 좋을 것 같아요
더 자세한 가져오기 정보들은 공식 문서에 잘 적용되어 있습니다!!
테스트 세팅하고 테스트 코드 작성하는데 시간이 엄청 걸렸네요...
저희 멘토링 때도 말씀하셨던 말이
test코드를 짜기 어려운 이유는 그 컴포넌트가 애초에 어려운 컴포넌트 이기 때문이다
입니다...
컴포넌트를 잘게 나누는 것이 테스트 코드 작성에 훨씬 더 쉬운 방법이 될 것 같습니다!!
컴포넌트에서 보여주거나 기능하는 것이 작아지면 test할 것도 더 쉬워지는 것 같습니다.
그리고 test코드를 작성하고 컴포넌트 작성하는 건 진짜 경험의 유무에 따라 가능한 것 같습니다...
test코드가 당시의 기능을 만들기 위해서만 필요한 것이 아니라 서비스가 지속 가능하게 발전하기 위해 필요한 코드이기 때문에 공부하는 입장에서는 충분히 component를 작성하고 나서 중요한 기능을 test 코드로 만들어서 작업해도 좋을 것 같습니다.