간단하게 더 안정적인 어플리케이션을 만들 수 있기 때문이다.디버깅 시간을 단축! 만약 데이터가 잘못 나왔다면 프론트 문제인지 백 문제인지 등 전부 테스트를 통해서 찾아봐야하는데 테스팅 환경이 구축이 되면 쉽게 찾아낼 수 있다.안정적인 어플리케이션이 밖에도 재설계 시간의
getBy는 일치하는 요소가 없으면 => 오류를 발생queryBy는 일치하는 요소가 없으면 => null을 반환
테스트 코드를 작성하는데 userEvent.type이 잘 작동되지 않는 문제를 마주했다.(처음엔 toHaveTextContent 부분에서 에러가 나길래 이게 문젠줄 알았다. 확인해보니 userEvent 자체가 제대로 작동이 안된거다.그러니 당연 toHaveTextCon
또 다시 userEvent사용이 안되는 경우가 발생했다.이번엔 click메소드가 사용안됐는데.. 뭐가 문제지? await을 안붙였다..ㅠ 분명 나같은 사람있을것같아서 추가해 놓는다.
context를 사용하기위해 Provider로 해당 컴포넌트를 감싸주었지만, 테스트 부분에서는 감싸주지 않았기 때문에 Context를 사용할때 에러가 나고 있다.참고 OrderContextProvider이 반환하는건 context의 Provider 태그다.
작성한 테스트 케이스들 중 skip을 할 수 있는 기능이 있는데, test.only를 이용하면 해당 테스트 페이지에서 only된 부분만 테스트를 진행하고 나머지는 skip 처리된다.
cra+redux+typescript조합으로 만들다가 테스트를 돌렸는데 에러가 발생했다.,스택 오버 플로우에서 보니 커스텀 제스트 매처를 jest-dom으로부터 가져와야 한다고 한다.공식문서를 보니, 굉장히 친절히 나와있는데, @testing-library/jest-d
어느 순간부터 테스트를 하는데 에러가 무수히나 도무지 무슨 문제인지 알 수 없었다.'텍스트가 다수의 엘리먼트로 쪼개진다?' 이건 또 무슨 말이람.. 에러 내용을 자세히 보면 상태를 변경하는 setState부분에서 에러가 발생하고 있었다.며칠동안 해결법을 찾는데 시간을