[4주차 메인토픽] 테스트

[zigsong]

하브루타 3기 마지막 주제, 마지막 미션에서 많은 크루들을 괴롭혔던

테스트 🔫 입니다.

도대체 이거 왜 해야 해? 🤯
정말이지 왜 해야 하는 걸까요?

페어와 함께 경험 나눠보아요!

☘️ 하위키워드 예시

• 테스트 비용
• 테스트 도구
• mocking
• E2E 테스트
• 단위 테스트
• reducer 테스트
• 관심사의 분리
• TDD, BDD
• 기타 테스트 경험 공유

⏳스터디 후 스레드에 각 페어당 소요시간 적어주세요!
(ex) 지그-크리스 90분 소요

[365kim]

공유하고싶은 자료 & 개인적으로 정리한 블로그 등이 있다면 여기👇👇👇에 댓글로 공유해주세요 😆

[365kim]

[Kent C. Dodds 번역] 테스트를 작성하라. 너무 많이는 말고. 통합 테스트를 많이 써라.
(⚠️주의) 중간에 단위테스트를 묘사하는 무시무시한 짤이 나옵니다.

[zereight]

통합테스트는 사기다
https://blog.thecodewhisperer.com/permalink/integrated-tests-are-a-scam

[365kim]

@zereight @sunhpark42

Q1

레벨1, 레벨2 미션 중 가장 유용했다고 생각되는 테스트 도구에 대해 함께 얘기해보아요 :)

• 사용했던 도구: cypress, storybook, jest, RTL
• cypress
  • 코드를 작성하는 이유가 사용자가 서비스를 정상적으로 이용하게끔 하는 것인데, 이에 대한 테스트를 작성하는 것이므로 유용하다.
  • 내부 구현에 영향을 받지 않기 때문에 기능이 유지되는 한 리팩토링을 해도 코드를 바꿀 필요가 없다. (상태 설계를 대대적으로 변경하더라도)
• Storybook
  • 스타일을 바로바로 찾아낼 수 있어 편리하다.
• Jest + RTL
  • 시간이 빠른게 장점이다. 새로고침되고 렌더되는 시간을 기다리지 않아도 된다.
  • 어디서 에러가 났는지 바로바로 캐치하는데 도움이 된다.

Q2

레벨3 때 단위테스트, 통합테스트 또는 E2E 테스트를 어떻게 진행할 예정인지 (테스트 도구, 테스트 커버리지) 대략적으로 함께 얘기해보아요 :)

• 하루
  • Cypress를 사용하고 싶다.
  • 주요기능을 테스트하되, 일정산출 능력이 부족하기 때문에 우선은 TDD 대신 기능을 구현하고 테스트를 덧붙이는 식으로 작성할 것 같다.
• 도비
  • Jest, RTL 을 사용하고 싶다.
  • 비즈니스 로직을 중요한 로직 부분만 TDD로 진행할 것 같다. E2E 테스트는 하지 않을 것 같다.
• 서니
  • Jest, RTL, Storybook 을 사용하고 싶다.
  • test-id를 사용할지는 아직 고민이다. (data-test-id 지워주는 바벨 플러그인))

[dudtjr913]

@swon3210

Q1

E2E 테스트, 통합 테스트, 단위 테스트가 서로 어떻게 다른지, 어떤 테스트를 사용해봤는지 토론해봐요!

테스트 범주: 
- 단위 테스트: 모듈
- 통합 테스트: 모듈, 모듈간의 연결
- E2E 테스트: 기능

테스트 중복: E2E > 통합 > 단위
테스트 비용: E2E > 통합 > 단위
유지보수 비용: 단위 > 통합 > E2E

크리스는 RTL로 단위 테스트를 하고, Cypress로 E2E 테스트를 해봤다고 한다. E2E 테스트를 강력하게 추천했는데,
이유는 사람의 눈으로 보기 힘든 버그를 발견할 수 있고, 그로 인해 어플리케이션이 더 견고해진다고 했다.

Q2

여유가 없음에도 불구하고 테스트를 해야할까요? 그 이유는 무엇일까요? (테스트의 장점 및 단점)
이와 더불어 레벨3 때 테스트를 할 계획이 있는지도 얘기해봅시다~!

여유가 너무 없으면 테스트를 하지 못할 것 같다. 하지만 되도록이면 단위테스트를 하려고 하고, 너무 여유가 없어서
단위테스트를 도저히 못할 상황이라면 E2E테스트는 하려고 한다. 

Q3

테스트 도구를 공부하고 코드에 적용하는 방법을 공유해보아요!

테스트 도구는 대체로 공식 문서보다는 유튜브 영상을 보는 편이다. 테스트를 바로 적용해야 하기 때문에 유튜브 영상을 보고,
부족한 것이 있으면 공식 문서를 참고한다. 영상을 보게 되면 공식 문서에서 얻을 수 없는 꿀팁도 많이 얻을 수 있어서 유용하다.

[zereight]

@sunhpark42 @365kim

1. 리뷰어님들 PR을 보면 개발하다보니 단위, 통합 테스트 위주로 작성하게 된다. production용 코드는 짜보지 못했다. 등등의 경험을 본적이 있어요. E2E 테스트는 잘 안하시는 것 같더라구요. 왜 그럴까요? 도쯔 아저씨의 테스팅 트로피에 통합테스트가 가장 비중이 큰것과 연관이 있을까요?

물론 모든 테스트를 하면 견고해지겠지만, 비용, 일정 다양한 상황등의 현실적인 문제 때문에 가성비가 좋은 테스트를 우선적으로 작성하는 것 같다.

2. jest로 mocking할 때, 제 머릿속에는 여러가지 방법이 떠오르는데요. 뭘 사용하는게 좋을까요? (안티패턴이든 성능이든 유지보수든 모든 관점에서)

window.alert를 mocking하는 상황

window.alert = () => {...};

window.alert.mockImplementation(() => {...});

jest.spyOn(window, 'alert').mockImplementation(...);

일반 함수라면 2번, 객체의 메서드를 모킹하는 것이라면 3번을 사용하여, 수정 대상에 직접 접근하여 수정하는 것을 지양하는게 좋을 것 같다.

[sunhpark42]

@zereight @365kim

Q1. 테스트는 왜 하는 걸까요? 가끔은 테스트 코드를 짜는데 시간이 더 소요되기도 하고, 리팩토링시 활용을 잘 안하기도 하는데요. 각자 테스트를 해서 이런점이 유용했다! 어떤 테스트는 좋았는데, 어떤 테스트는 불필요했다와 같이 여태까지 했던 테스트 경험에 대해 이야기를 나누어 보아요 :)

<하루>

* 처음에는 테스트 단위가 작아서 테스트에 의미가 있나 싶었는데, 리팩토링을 하다보니 코드수정에 따라 앱이 제대로 동작하지 않는 것을 보고나서 테스트를 하는 것이 의미있는 일이라는 것을 깨달음
* 지하철 미션에서 API가 여러개였어서 확인하는 것이 번거로웠다. cypress와 같이 e2e 테스트 코드를 짰다면 더 편리해을 것 같다.
* 리팩토링을 할 때 주는 심리적 안정감, 효율은 유의미한 것 같다.
* 한 번 리덕스가 적용돼있던 프로젝트에, swr을 사용하게 되어 리덕스와 관련한 코드 및 테스트코드를 모두 날렸다. 코드를 짜는데 들인 시간이 아까웠다.
* 단위테스트가 필요한지는 잘 모르겠다.
* 사이프레스 처럼 초론색 v 가 뜨는 것이 테스트를 할 때 즐거움을 주는 부분이다.

<도비>

* 제작근로를 하면서 요구사항이 바뀌는 경우세 수정하다보면, 테스트가 깨지는 경우가 많았는데 코드를 수정하거나, 리팩토링을 할 때 바로바로 버그를 잡을 수 있어서 효율적이라고 느꼈다.
* expect 를 이용하면 무엇을 테스트했고, 어떻게 결과가 다르게 나왔는지 diff를 확인할 수 있음.
* for 문을 이용해 여러개를 테스트하면 어디서 에러가 나는지 알기 어려워서, 각각 돌리는 것이 나은 것 같다.
* 요구사항이 잘 짜여있는지, 테스트 하기에 용이하게 기능을 구현하고 있는지 확인할 수 있음.
* 테스트는 프로젝트를 견고하게 만들어준다.

<서니>

* 예전엔 필요성을 못느꼈는데, 요즘 리팩토링을 할 때 유용하게 사용하고 있음.
* 대대적으로 큰 변화가 필요했는데, 그때 바로 어디에서 에러가나는지 확인하고 수정할 수 있어서 효율젹이었다.
* test-id를 안쓰려다보니, aria-label을 꽤 많이 이용했다.
* 그런데 test-id 제외하고 build가 가능하다는걸 알게 되어서 적용해볼 생각
* https://yarnpkg.com/package/babel-plugin-remove-data-test-id-attribute

Q2. 프론트엔드에서 테스트주도 개발은 어떻게 진행 될 수 있을까요?

참고 영상 : 프론트엔드에서 TDD가 가능하다는 것을 보여드립니다
* TDD를 하면 피드백이 빠르고 바로바로 왔다갔다하면서 기능을 구현할 수 있따..
* 단위를 어떻게 잡느냐에 따라 적절하게 사용할 수 있을 것 같다.
* 프론트에서 테스트를 시각적, 기능적인 부분을 쪼개서 생각할 수 있다.
* 기능은 TDD를 하는 것이 좋다고 생각함.
* 유닛테스트 는 가능 할 것 같은데 통합, e2e테스트의 경우에는 돔 요소를 가져와야해서 애매한 것 같다.
* (서니) 요즘 그냥 코드짜고, 테스트짜고, 리팩토링할 때 테스트 코드를 이용한다. 세미 TDD, 통합테스트를 할  때에는 유용하다고 생각.
* 아직 테스트 코드 자체에 대한 신뢰도가 떨어진다. 기능은 완벽한데 테스트코드가 잘못된 경우가 많아서 드는 불신이 있는것 같다.
* TDD를 하기 위해선 테스트도구에 대한 숙련도가 요구되고, 요구사항 바뀌더라도 기능 삭제 등 치명적이지 않고 기존 기능을 조금씩 수정할 때 유용한 것 같다.

[swon3210]

To. 디토 @dudtjr913

Q1. 단위 테스트에서 가장 중요한 것은 '관심사의 분리' 라고들 말하는데요, 여기서 관심사의 분리란 무엇이고, 컴포넌트, 페이지, 리덕스 혹은 훅 별로 어떻게 관심사를 구분할 수 있을까요?

관심사의 분리란 하나의 기능을 테스트할 때, 여러 조건이 있을 수 있는데 그것을 최대한
작게 분리해서 테스트를 하는 것이다. 예를 들어 a일 땐 "a"가 나와야 하고, b일 땐 "b"가
나와야 한다면 a가 나오는 테스트, b가 나오는 테스트를 각각 만들어서 관심사를 분리하는 것이다.
이렇게 하면 테스트의 유지보수도 좋아지고, 디버깅도 쉬워진다.

컴포넌트: 렌더링 여부, 이벤트 단위로 테스트(클릭 이벤트, 입력 이벤트)
페이지: 페이지도 단위 테스트인가요?
리덕스: 상태 변경 여부, 에러 상황
훅: 함수 호출, 상태 변경 여부

Q2. E2E 테스트 & 단위테스트 & 통합테스트 별로 테스트 비용의 순위를 매겨보고 그 이유를 함께 나누어봅시다!

비용 : E2E > 통합 > 단위테스트

단위테스트: 하나의 기능 또는 하나의 컴포넌트를 테스트하는 것으로 여러 기능이 얽혀서 테스트를
하는 통합이나 E2E테스트보다 테스트를 구축하는 비용이 적게 든다. 하지만 실제 어플리케이션에서는
여러가지 기능이 통합되어 작동하기 때문에 적절하게 데이터를 모킹해서 사용해야 한다.

통합테스트: 여러 컴포넌트의 상호작용, 하나의 페이지를 테스트하는 것으로 해당 페이지에서
사용되고 있는 모든 컴포넌트들이 동작하는 상황에서 테스트를 진행하기 때문에 단위테스트보다
테스트 구축 비용이 높다. 한 페이지에서 어떤 기능을 실행했을 때, 연계되어서 변경되는
다른 기능까지 테스트를 해야한다.

E2E테스트: 사용자 입장에서 전체적으로 어플리케이션이 잘 동작하는지 확인하는 테스트로서, 
페이지 간 이동이 잘 되는지, 시간은 얼마나 걸리는지 등을 테스트해야 한다. 전체적인 페이지를
모두 테스트하는 만큼 테스트 비용이 높고, 고려해야 할 사항도 굉장히 많다.

Q3. 3단계 미션에서 적용해볼 수 있는 테스트는 어떤 테스트이고, 어떤 이점과 비용이 있을지 이야기 해봅시다!

react-testing-library를 사용해서 페이지 통합 테스트를 할 수 있고, jest를 사용해서
리덕스 단위 테스트를 할 수 있다고 생각한다. 

하지만 실제 프로젝트 기간이 6주이기 때문에 테스트까지 고려하기는 힘들 수도 있다고 생각한다.
그래서 만약 테스트를 한다고 하면 그만큼 기능을 포기해야 할 것 같고, 그것이 비용이라고 생각한다.
레벨 3은 기능에 초점을 둔 프로젝트이고, 레벨 4가 리팩토링에 초점을 두고 있다고 알고 있는데,
테스트의 이점은 리팩토링을 할 때 나타난다고 생각하기에 레벨 3에서 테스트를 할지는 잘 모르겠다.

요약해서 테스트를 하면 레벨 4에서 리팩토링을 할 때 자신감을 가지고 편하게 할 수 있을 것이지만
원하는 기능을 모두 만들지 못해서 포기해야 할 기능이 생길 것이라서 잘 조절을 해야할 것 같다.

[iborymagic]

@yujo11

Q1. 지하철 미션에서 어떤 도구를 사용해서, 어떤 방식으로 테스트를 진행하였는지에 대해 경험을 공유해주세용

React Testing Library를 이용해서 컴포넌트 단위 테스트를 하려고 했다.
근데, 어느 단위로 쪼개서 테스트를 해야 할지가 굉장히 애매했다.
단일 컴포넌트를 테스트하려니, 예를 들어 Toggle Button 컴포넌트를 만들었다고 치면
버튼이 Toggle 되는지까지 테스트를 해야 하나? 이런 것들.

그래서 컴포넌트 테스트를 한다고 했지만, 결국에는 페이지 단위로 통합 테스트를 진행한 듯.
심지어 말은 통합테스트인데, 뭔가 E2E 테스트처럼 진행한 것 같음.
아직 리액트 테스트에 대해서는 감이 잘 안 잡힌다.

Q2. 본인이 생각하기에, 테스트 코드를 작성해서 얻을 수 있는 이점에는 어떤 것들이 있는 것 같은지 말씀해주세용

일단 TDD를 한다고 했을 때, 테스트 코드의 장점은 구조적인 부분을 먼저 정하고 들어갈 수 있다는 점.
예를 들면, 내가 Toggle Button을 만든다고 구조를 정해놨는데 중간에 자꾸 딴 생각이 들수도 있다.
Radio Button으로 바꿔야 하나? 이런 것들.

테스트 코드를 먼저 작성하고 들어가면, 테스트 코드 작성 또한 비용이기 때문에 흔들릴 여지가 적어진다.
그래서 명세를 거의 확정하고 개발에 들어갈 수 있다는 점이 장점으로 작용할 수 있다고 생각.

굳이 TDD가 아니고 그냥 개발하는 과정에 있어서도, 해당 기능을 완성하기 위해서는 결국 테스트를 통과해야하기 때문에
개발하는 과정에서 발생하는 실수들을 줄일 수 있다.
리팩토링을 할 때 모든 기능에 대한 테스트를 매번 하나하나 할 수 없으니,
그걸 자동화해서 리팩토링 이후에 사이드 이펙트가 생기는지 여부를 빠르게 파악할 수 있다.
그래서 전체적인 개발 속도가 전체적으로 올라간다고 생각.
사실 이 부분에서 가장 테스트의 장점이 많이 체감됐다.

[yujo11]

@iborymagic

1. 아래 적혀있는 테스트들의 특징을 얘기해봐요!

1. Static(정적) - 개발된 프로그램을 돌려보지 않고 명세나 코드만 보고 테스트하는 방법 ESLint, Prettier
2. Unit(단위 테스트) - 작은 단위를 전체 앱에서 떼어 내어 분리된 환경에서 테스트 하는 것. 하나의 모듈에 대해서 세밀한 부분까지 테스트 가능
   • 그러나, 의존성 있는 모듈을 제어하기 위해 Mocking이 필수적
3. Intergration(통합 테스트) - 두 개 이상의 모듈이 실제로 연결된 상태를 테스트한다. 모듈이 동시에 상호작용하는 것을 테스트하기 때문에 단위 테스트에 비해 Mocking의 사용이 적다.
   • 그러나, 단위 테스트에 비해 테스트가 번거롭고, 테스트 중복이 발생할 확률이 높다.
4. E2E 테스트 : 처음부터 끝까지 사용자의 관점에서 테스트를 진행, 코드 내부 구조에 큰 영향을 받지 않기 떄문에 코드 변경에 유연하다.
   • 그러나, 속도가 느리고 테스트 중복이 발생할 수 있다. 또한 테스트 실행 환경에서 예상치 못한 문제(네트워크 오류, 프로세스 대기로 인한 타임아웃 등)로 인해 테스트가 실패할 수 있다.

2. 각 테스트들의 차이와 어떤 경우에 어떤 테스트를 적용하면 좋을지 얘기해봐요!

• 정적 테스트 : 모든 개발에 거의 필수적이라고 생각, 휴먼 에러를 엄청나게 줄여준다.
• 단위 테스트 : 메서드 하나하나에 대한 테스트를 작성하는 것이기 때문에 TDD를 할 때 단위 테스트를 통해 개발하면 좋을거 같다. 정확히 어느 부분에 이상이 있는지 파악할 수 있기 때문에 버그 픽스에 유리함.
• 통합 테스트 : 단위 테스트로 테스트하기 에매하고 E2E테스트를 하기도 에매할 때, 단위 테스트 여러개를 연결해서 잘 동작하는지 테스트 할 때
• E2E 테스트 : 사용자의 관점에서 상호작용을 테스트하는 만큼, 실제 프로덕트를 내기 전, 꼭 수행해야할 테스트인거 같다. 단위, 통합 테스트에서 문제가 없더라도 컴포넌트들이 연결됐을 때 문제가 생길수도 있다.