테스트를 작성하자. 너무 많이는 말고. 통합 위주로(Write tests. Not too many. Mostly integration.)

얼마전에 Guillermo Rauch 이것을 트윗 했다. 이것이 무슨 의미인지 한번 살펴보자.
참고: 이글은 내가 보내는 뉴스 레터와 같은 내용이다. 이메일 발송 2 주 후에 글로 게시한다. 뉴스레터를 구독해서 더 많은 콘텐츠를 받아보자! 💌
얼마전에, Guillermo Rauch‏ (Socket.io 를 만들었으며 Zeit.co의 파운더(최근에 나온 엄청나게 멋진 것들을 제작한 회사))가 중요한 내용을 트윗 했다:
presentation
테스트를 작성하자. 너무 많이는 말고. 통합(integration) 테스트 위주로.
짧은 내용이지만 중요한 내용이니, 한번 파고 들어가 보자:
테스트를 작성하자.
맞다, 대부분의 프로젝트에선 테스트를 작성해야 한다. 시간을 소중히 여겨야 한다. 아침 2시에 전화를 받고 문제를 해결하는 것보다 테스트에서 버그를 잡는 것이 훨씬 낫다. 나는 종종 테스트 코드를 작성 했기 때문에, 시간을 절약하는 경우가 있다. 테스트 코드를 작성하면서 앱을 개발하게 되면 시간이 더 오래 걸릴 수도 있고 그렇지 않을 수도 있다. 그러나, 테스트 코드가 있다면 나는 (그리고 다른 사람들 역시) 유지 보수에 투자하는 시간을 거의 확실히 절약 할 수 있다.
테스트 코드를 작성할 때 고려해야 할 것은 이 테스트 코드가 프로젝트에 버그가 없다는 확신을 얼마나 줄 수 있는지이다. Flow 및 ESLint와 같은 정적 타이핑 및 linting 도구는 코드에 상당한 신뢰를 줄 수 있으며, 이러한 도구를 사용하지 않는다면 이러한 것들을 도입 하는 것을 강력히 권장한다. 즉, 강 타입 언어(a strongly typed language) 일지라도 테스트가 있어야한다는 것이다. 타이핑과 linting은 비즈니스 로직에 버그가 없음을 보장 할 수 없다. 따라서 여전히 훌륭한 테스트 코드로 자신감을 높힐 수 있다.
너무 많이는 말고.
어떤 관리자와 팀은 애플리케이션에 대해 100% 코드 커버리지를 요구한다고 들었다. 그것은 정말 좋지 않은 생각이다. 이것의 문제는 코드 커버리지가 70%가 넘어가면 효과가 반감된다는 것이다(과학적 근거는 없다...). 왜 그럴까? 항상 100% 코드 커버리지를 도달하기 위해 노력할 때, 실제로 테스트 할 필요가 없는 것들을 테스트하는 데 시간을 할애 해야 할 경우가 있기 때문이다. 로직이 전혀없는 것들 (그래서 ESLint와 Flow가 버그를 잡을 수 있다). 이와 같은 테스트를 유지하면 실제로 팀이 속도가 느려지거나 실패 할 수 있다.
테스트 환경에서 재현하기 어려운 한 줄의 코드를 위해 구현 세부 사항을 테스트 하려고 하는 경우가 있을 것이다. 구현 세부 사항을 테스트하는 것을 피하는 게 좋다. 왜냐하면, 이것을 테스트한다고 해서 애플리케이션이 작동 할거라는 확신을 주지 않을 뿐더러 리팩토링에 시간이 많이 걸리기 때문이다. 코드를 리팩토링 할 때 테스트를 변경해야하는 경우는 거의 없어야 한다.
나의 거의 모든 오픈 소스 프로젝트에는 코드 커버리지가 100% 임을 언급해야 할 것 같다. 이것은 내 오픈 소스 프로젝트의 대부분이 여러 다른 상황에서 재사용 할 수 있는 작은 라이브러리 및 도구이기 때문에 (코드가 깨지면(breakage) 많은 프로젝트에서 심각한 문제로 이어질 수 있다) 100% 코드 커버리지를 비교적 쉽게 도달 할 수 있기 때문이다.
통합(integration) 테스트 위주로.
테스트 방법에는 많은 타입이 있다 (Fluent Conf에서 발표한 5분 가량 되는 발표를 확인하자: "What we can learn about testing from the wheel"). 각각의 테스트 방법에는 장단점이 있다. 테스트에 관해 이야기 할 때 가장 일반적으로 말하는 세 가지 테스트 유형은 단위(Unit), 통합(Integration) 및 E2E(End to End)이다.
presentation
이 테스트 피라미드 그림은 마틴 파울러 (Martin Fowler)의 블로그와 Google 테스트 블로그에서 가져온 것을 조합한 것이다.
그림에 나온대로 피라미드는 아래에서 위로 보여준다: Unit, Integration, E2E. 위로 올라감에 따라 테스트는 작성/실행하는데 오래 걸리고, 실행/유지하는 데 더 많은 시간과 리소스가 소요된다. 이 요인들 때문에 단위 테스트에 더 많은 시간을 투자 해야한다는 것을 의미한다.
그것이 보여주지 않는 한가지는 당신이 피라미드의 위로 움직일 때마다, 테스트의 각 형태에 대한 신뢰 지수가 증가한다는 것이다. 투자한 노력 대비 본전을 뽑고도 남는 다는 것이다(You get more bang for your buck). 따라서 E2E 테스트는 단위 테스트보다 느리고 비용이 많이 들지만 애플리케이션이 의도 한대로 작동하고 있음을 더욱 확신 할 수 있다.
내 트윗중 가장 리트윗이 많이 된 이것은 단위 테스트의 중요한 이슈와 관련이 있다:
난 여전히 이게 좋아. 단위 테스터는 이렇게 생각 하는 것 같다: "잘 작동하는 것 같은데."
presentation
이 사람이 제자리에서 달릴 수 있고, 팔굽혀펴기를 하고, 읽을 수 있는지 확인하는 단위 테스트를 작성했지만 그의 다양한 신체 부위들과 통합되지 않았다. 해당 핸들러가 올바른 데이터로 올바른 요청을하지 않으면 버튼 컴포넌트가 onClick 핸들러를 호출하는지 여부는 중요하지 않다! 따라서 이러한 조각들이 독립적으로 작동하는지 확인하기 위해 단위 테스트를하는 것은 나쁜 것은 아니지만 이런 것들이 함께 작동하는지 또한 확인하지 않으면 아무런 이득이 없다.
통합 테스트는 자신감과 속도/비용 사이의 절충점에서 큰 균형을 이룬다. 이런 이유로 대부분의 노력(전부가 아닌)을 거기에 소비하는 것이 좋다.

더 많은 통합 테스트를 작성하는 방법
통합과 단위 테스트 사이의 선은 약간 애매하다. 그럼에도 불구하고 더 많은 통합 테스트를 작성하기 위해 할 수있는 가장 큰 일은 모킹(mocking)을 너무 많이 하지 않는 것이다. 무언가를 mocking하게 되면 테스트하고 있는 것과 mocking한 것 사이의 통합에 대한 확신을 근본적으로 제거하는 것이 된다. 때로는 이것이 도움이되지 않을 수도 있음을 이해한다 (일부는 동의하지 않지만). 매번 테스트 할때마다 이메일을 보내거나 신용 카드 청구를 하고 싶지는 않을 테지만, 대부분의 경우 mocking을 피할 수 있다. 그리고 그렇게 하는 것이 더 낫다.
리액트(React)를 사용하고 있다면 얕은 렌더링(shallow rendering)이 이에 포함된다. 나는 오랜 시간 동안 얕은 렌더링이 구현 세부 사항을 테스트하고 있다고 느꼈다. 이것에 대해 더 알고 싶다면 3분짜리 팟 캐스트(그리고 리액트 테스트를위한 다른 팁)를 참고하자.
이것이 도움이 됐으면 좋겠다! 행운을 빈다!👍
놓치지 말아야 할 것:
  • blog.kentcdodds.com — 미디엄에서 블로그 포스팅을 시작했다. 여기서 나를 팔로우 할 수 있다!
  • hacktoberfest — 깃헙으로 가입하고 10월에 4개의 풀 리퀘스트를 보내면 여기서 무료 셔츠를 보내준다. 훌륭하지 않나!?
  • draggable - 내가 본 가장 쿨한 데모가 있는 프로젝트.
  • Funky Karts demo — 웹 어셈블리로 만들어진 쿨한 게임. Jay Phelps 고맙다!


Dohyung Ahn 님께서도 같은 글을 먼저 번역한 글도 있으니 제 글이 좀 어색하다면 아래 글을 한번 확인해보시면 좋을 것 같습니다.
https://medium.com/@rinae/번역-테스트를-작성하라-너무-많이는-말고-통합-테스트를-많이-써라-4cb9511b300d


이 글은 번역글 입니다. 혹시 오역이나 잘못된 부분 있으면 알려주시면 수정하도록 하겠습니다.
원문