jest에서 cypress로 테스트 프레임워크를 바꿔야겠다고 결심했다가 취소한 이유

- jest를 선택한 이유

통합테스트는 단위테스트와 e2e테스트의 중간의 테스트 기법임.

그렇기에 통합테스트를 한다는 것은, 단위테스트와 e2e테스트의 장점을 동시에 가져갈 수 있으므로 가성비가 좋은 테스트라고 할 수 있기에 jest를 이용해서 사용.

 

- jest에서 cypress로 바꿔보려고 결심한 이유

페이지 단위로 나누어 핵심 기능들을 테스트했고, 해당 테스트를 위해서는 매번 use~~로 시작하는 api를 비동기 요청하고 있는 커스텀훅들을 모킹해주어야 했고, 로직이 크게 변경되면 테스트 코드를 여러군데 많이 손보아야 했음.

 

이렇다보니 테스트코드가 정말 버그를 잡는 용도로서의 기능보다, 테스트 코드가 작성되있는 프로젝트야~ 라는 느낌의 테스트코드만 작성하게됨.

테스트가 유의미하다고 느껴지지 않을 정도의 테스트가 여러개 생성되는 느낌을 받음.

 

또한, 에러가 났을때, terminal에서 친절하게 오류를 알려주지도 않았음.

매번 스크롤을 쫙 올려서 어떤 오류인지 확인하는거 불편...

 

현재 테스트 수준이, 페이지 단위의 E2E테스트 같은 느낌이기 때문에 굳이 jest를 사용할 필요가 없다고 생각.

오히려 cypress를 사용하는 것이 api 모킹도 쉽고 테스트 디버깅이 쉽다고 판단.

 

즉,

jest의 통합테스트로 어중간한 E2E를 흉내내지말고, cypress로 제대로된 유의미한 E2E 테스트 코드를 작성해보자

의 마인드로 결심을 내리게되었다.

물론 cypress와 jest의 장단점이 있다.

cypress는 E2E이기 떄문에, 내부 함수 모킹이 안되고, 작성시간도 길다는 단점으로 이 결심이 끝까지 갈지는 모르곘지만,

충분히 의미있는 행동이라고 느껴진다.

 

- 다시 jest로 변심

cypress를 도입하기 위해, 코드를 다시 복습하고 적용을 해보았다.

확실히, 테스트 목록을 뽑을때, 유저의 입장에서 테스트코드를 작성하니 목록이 자세하게 나왔다.

하지만, 아무리 번들결과에 testid를 제거하는 webpack plugin을 사용한다고 해도, 필요한 모든 element에 testid가 붙는건 좀 아닌것 같다.

또한, 실행결과가 오래걸린다. headless로 돌린다해도 jest보다 수행시간이 많이 길었고, E2E다 보니 테스트 코드를 작성하는 시간도 많이 소요되는것 같았다.

앞으로 적용할 기능과 성능개선과 수정사항이 많은데, E2E 테스트를 작성하는데 너무 많은 시간이 소모될것같아서,

jest 테스트 코드를 의미있게 작성하는 방향으로 다시 방향을 잡아와야겠다.