• 카테고리

    질문 & 답변
  • 세부 분야

    프론트엔드

  • 해결 여부

    해결됨

cypress 와 jest에서 타입만 다르다면? 그래도 같이 쓰는것도 좋지 않나요?

24.04.27 23:53 작성 조회수 87

2

cypress를 적용해보고 러닝 커브가 훨씬 낮은거 같고 좋았습니다 jest는 많이 목킹을 하고 여러가지 더 설정이 많아서 힘들긴 했는데 여기서 타입을 제외하고 더 같이 쓰지 말아야할 이유가 있나요?

답변 2

·

답변을 작성해보세요.

0

저도 위 답변과 동일하게 생각합니다 하지만 강의상에서는 "1. 같이 쓰는 거는 진짜 하지 마시고" 아예 같이 사용하면 안된다 라는 느낌이 강하게 듭니다 그래서 왜? 그렇게 생각하셨는지 선생님의 경험을 듣고 싶었습니다. 하지만 단순히 "프론트엔드에서 유닛테스트, 통합테스트, e2e 테스트의 경계가 굉장히 모호하다" 라는것은 그 경계를 정하면 되는것인데 이게 바로 팀 컨벤션이겠죠 이렇게 확고하게 말씀하신게 이상하다 라고 생각했습니다.
이런 이유라면 확고한 표현은 수강생들에게 혼동을 줄수있을거 같습니다 아니라면 더 경험을 듣고 싶습니다. 둘이 같이 사용해서 문제가 생겼던 적이 있었던건가요?

제 경험을 통해 말씀드리자면. 타입 설정관련 해서는 이미 충분히 공감대가 있는것 같으니 제외하고,

 

  1. 처음 테스트코드를 도입할 때 테스트 커버지에 집착해서 jest와 cypress를 같이 사용했습니다. 처음 도입할 때는 의욕이 넘쳐서 모든 기능을 테스트 하고자했었습니다.

  2. 그런데 새로운 개발자가 팀에 합류할 때도 문제가 됐습니다. 온보딩 하는 개발자는 두가지 테스트 스택을 모두 학습했어야 했고. 자연스럽게 온보딩 시간이 길어지더라구요. 특히 테스트코드 작성 경험이 없는 분이 합류했을 때는 더 오래걸렸습니다.

  3. 그리고 사용하는 스택이 다양하니 자연스럽게 컨벤션도 복잡해집니다. 유닛테스트는 어디까지 하고 통합테스트는 어디까지하고 e2e 테스트는 어디까지 하고 이런 것들을 정하는 것도 꽤나 오래 걸리더라구요

  4. 결국 저와 저희 팀이 도달한 결론은 “우리는 점점 테스트를 위한 테스트를 하고있다” 였습니다. 그래서 꼭 테스트 해야하는 부분만 테스트 하는 식으로 피벗했고 그러면서 cypress로 정착했습니다.

  5. cypress로 정착한 이유는 mocking이 더 간단하고 jest보다 제공하는 기능이 더 많다고 판단해서 입니다.

     

     

    꼼꼼하게 듣고 질문 해주셔서 감사합니다! 같은 의문을 가진 다른 분들께도 좋은 답변이 되었으면 좋겠네요. 추가로 궁금한 부분이 더 있으시면 말씀해주세요!

경험을 공유해주셔서 감사합니다!! 여러가지 의문이 풀리는거 같습니다 정말 감사드리고 오늘 좋은 하루 보내셨으면 좋겠습니다 다시 한번 감사합니다!

0

cafe small house님 안녕하세요!

말씀하신 것처럼 jest와 cypress중 하나만 선택해서 사용할 이유는 없습니다.

unit test를 작성하기에는 jest가 더 적합하고

e2e테스트를 작성할 때는 Cypress가 더 적합하니,

팀의 컨벤션이나 방향에 맞게 하나만 선택하셔도 되고, 두 패키지 모두 사용하셔도 괜찮다고 생각합니다.

 

다만 개인적으로는 프론트엔드에서 유닛테스트, 통합테스트, e2e 테스트의 경계가 굉장히 모호하다고 생각해서

굳이 두개의 패키지를 모두 활용해서 테스트 커버리지를 가져갈 필요는 없다고 생각합니다.

팀 상황에 맞게 잘 선택하시면 될 것 같아요!