React testing library의 전략

May 21, 2020

동기

React에 TDD를 적용을 하기로 마음을 먹고 testing library를 써보기로 했습니다. 과연 Enzyme 과는 어떤면이 다르고, 컴포넌트를 어떻게 테스팅을 진행 해야 할까를 고민하던 중 Kent C. Dodds 의 블로그 몇개를 읽고 난 생각과 번역을 적어 보려고 합니다. 출처는 맨 아래 참고에 올려 두겠습니다.

고민

testing library 를 사용하다 보면 컴포넌트의 부모 컴포넌트에서 자식 컴포넌트가 테스팅 해야 할 것들도 작성하는 듯한 느낌을 받았습니다. ( 이게 사실 testing library에서 원했던 것일 수 있습니다. ) 자식 컴포넌트도 테스트를 작성하게 된다면 테스트 들이 너무 중복되진 않을까?? 하는 질문에서 다음과 같은 stack overflow를 발견합니다.

https://github.com/testing-library/react-testing-library/issues/167

Testing Library 의 목표는 다음과 같이 나와있습니다.

As a part of this goal, you want your tests to avoid including implementation details so refactors of your components (changes to implementation but not functionality) don't break your tests and slow you and your team down.

unit-vs-integration-vs-e2e-tests

프론트 엔드 테스팅에는 다음과 같은 전략이 있습니다.

End to End 테스트

사용자처럼 앱을 클릭하고 올바르게 작동하는지 확인하는 도우미 로봇입니다. "기능 테스트" 또는 E2E 라고도합니다. 이 방법은 전체 어플리케이션을 실행하면서 일반 사용자 처럼 앱과 상호 작용 합니다. 일반적으로 테스트 양이 많아 비용이 크고 느리며 또한 많은 실패 지점이 생겨서 테스트가 중단 될 가능성이 높아져 테스트를 분석하고 수정하는데 더 많은 시간이 필요합니다.

통합 테스트

여러 장치가 조화롭게 작동하는지 확인하는 테스트. 대부분의 통합 테스트는 전체 앱을 렌더링 하지 않습니다. 하지만 앱에서 사용하는 모든 제공자(컴포넌트)들을 render 할 수 있습니다. 통합 테스트는 기본 개념은 가능한 한 mock을 만들지 않는 것입니다. 보통 사용자의 행위 및 보이는 것에 대해서 테스트를 진행하게 됩니다. ( 버튼이 클릭이 되고, 텍스트가 보이고 UI 가 보이고 에 대한 테스트 입니다. ) 어떤 HTML이 쓰였는지 그런것에 대한건 중요치 않습니다.

단위 테스트

분리 된 개별 부품이 예상대로 작동하는지 확인하십시오. 순수 함수일 때 유닛 테스트 하기 가장 좋습니다. 비용이 적고, 테스트 하기 빠릅니다. 만약 비용과 속도 측면에서 절충안을 찾는다면 100% 단위 테스트로 진행할 것입니다. 일반적으로 종속성이 없는 작은 항목을 테스트 하거나 해당 종속성을 mock해서 테스트를 진행합니다.

우리가 테스트를 작성하는 이유

테스트를 작성하는 가장 큰 가장 중요한 이유는 자신감입니다. 미래를 위해 작성한 코드가 현재 프로덕션에서 실행중인 앱을 중단시키지 않을 것이라고 확신하고 싶습니다. 그래서 내가 무엇을하든, 내가 작성하는 테스트 종류가 최대한 자신감을 갖게하고 테스트 할 때 해당 테스팅의 타협점(과연 어디까지 이 테스트 코드로 보장을 할 것인가?)을 인식 해야합니다.

테스팅의 타협에는 다음과 같은 종류가 있습니다. 비용, 시간, 신뢰성(확신)

비용

E2E 테스트로 갈 수록 비용은 비싸집니다. 지속적인 통합 환경에서 테스팅을 진행할때 실제 비용이 들기도 하지만 엔지니어가 각 테스트 를 작성하고 유지 관리하는데 들어가는 시간 또한 들어갑니다. 또한 더 많은 실패 지점이 생겨 테스트가 중단 될 가능성이 높아져 테스트를 분석하고 수정하는 데 더 많은 시간이 필요합니다.

속도

E2E 테스트로 갈 수록 속도는 느려집니다. 테스트 실행 코드가 많기 때문입니다. 단위 테스트는 전통적으로 테스트가 작습니다. 이는 디펜던시들이 없거나 mock 디펜던시(수천 줄의 라인을 단 몇줄로 줄여줍니다.)를 이용하기 때문입니다.

신뢰성(확신)

유닛 테스트에서는 간단한 문제에 대한 신뢰성이 있는가 반면 E2E를 통한 테스트는 큰 문제에 대한 신뢰성이 있습니다.

테스트들이 소프트웨어 사용 방식과 유사 할수록 더 많은 확신을 줄 수 있습니다.

각 테스트들의 특성을 알아본다면 다음과 같을 것입니다. 단위 테스트는 호출 한 종속성에 대해 호출할 때 적절하게 호출되는지는 확인 할 수 없습니다. ( 어떻게 호출되는지 확인할 순 있지만, 정확히 호출이 되어지는지 확신할 순 없습니다. ) UI 통합 테스트는 백엔드와 데이터가 제대로 주고 받는지 확인할 수 없고 에러에 대해서 정확하게 응답하는지 확인 할 수가 없습니다. End to End 테스트는 꽤 유용하지만, 전형적으로 실제 production 환경이 아닌 곳에서 테스트를 진행해서 실제 환경을 위한 신뢰성을 절충합니다.

여기서 E2E 테스트를 진행 한다면 "신뢰 계수" 라고 불리는 것이 올라갑니다. 즉, 어플리케이션이 성공적으로 움직인다는 것을 그만큼 보장하기 때문입니다. 하지만 비용과 시간을 더 들 것입니다. 단위 테스트를 진행 할 경우에는 테스트 코드 라인은 줄어 들 수 있지만 어플리케이션 코드 라인 만큼 커버하기 위해 테스트는 더 작성해야 합니다. 또 사실 낮은 레벨의 테스트에서는 몇몇 테스트는 불가능 합니다. 특히 정적 분석 도구(Typescript 같은)는 비지니스 로직에 대한 자신감을 줄 수 없습니다.

다른 사례를 봅시다. 폼과 URL 생성기를 통합한 엣지 케이스(예측 가능한 일정한 범위를 넘는 경우)를 위해 특정 필드에 입력한 값과 submit 버튼을 클릭 했을때를 E2E 테스트로 확인하는 것은 많은 양의 시간을 application 이 잘 돌아갈 수 있게 하는 것에 시간을 쏟을 것입니다.

이럴땐 통합 테스트가 더 잘 어울릴 수 있습니다. 실제 사용하는 컴포넌트를 렌더링할 수 있고 유닛 테스트에서 에지 케이스를 더 잘 커버할 수 있는지 확인하기 위해 설정 기능에서 상당한 양의 작업을 수행할 수 있습니다.

만약에 단위 테스트를 사용하여 숫자 대신 문자열로 add 함수를 호출 할 때 발생하는 상황을 확인하려고하면 TypeScript와 같은 정적 유형 검사 도구를 사용하는 것이 훨씬 좋습니다.

결론

E2E 테스트는 많은 양의 테스트로 인해 어떤 코드로 인해 실패를 했는지 추적하기가 어려워지지만, 그 의미는 곧 그 테스트가 자신감을 좀 더 올려줄 수 있다는 의미가 됩니다. 테스트를 작성할 시간이 충분하지 않은 경우에 특히 유용합니다. 차라리 자신감을 가지고 테스트를 통해 문제를 발견하지 못한 것보다 실패 이유를 추적하는 데 어려움을 겪고 싶습니다.

사실 이런 테스트 전략의 차이점 보다는 나의 코드가 변하고자 할때 나의 코드가 비지니스 요구에 만족하고, 다양한 테스팅 전략을 사용해서 목표에 도달할 수 있는 자신감을 가질 수 있는지에 대해서 더 관심이 많아야 할 것 입니다.

얕은 렌더링을 사용하지 않는 이유

얕은 렌더링을 사용하면 컴포넌트의 구현을 리팩토링 했을 경우 나의 테스트는 깨지게 되고, 얕은 렌더링을 사용하면 나의 application을 깨지게 했지만, 테스트는 여전히 돌아가게 됩니다. 얕은 렌더링은 실제로 DOM element와 상호작용하지 않습니다. 실제로 렌더링 되는건 없기 때문입니다. 또한 실제로 커스텀 컴포넌트에 의해 리턴된 엘리먼트는 얻을수가 없습니다.

왜 우리는 얕은 렌더링을 사용할까

리액트 컴포넌트의 메서드를 호출하기 위해.
각 컴포넌트의 children 모드를 렌더링하는게 낭비처럼 보이기 때문.
실제 단위 테스트를 위해 사용합니다. 테스팅에 노출 되어있는 컴포넌트는 유닛 테스트 동안 에러가 발생될 수 있는 새로운 디펜던시가 도입이 되어도 여전히 의도한 대로 작동할 수 있습니다.

리액트 컴포넌트의 메서드를 호출하기 위해

이 경우에는 실제로 메서드를 이벤트에 바인딩 할때 오타가 나거나 해도 테스트는 깨지지 않습니다. 메서드를 가지고 테스트를 진행 했기 때문입니다. 또한 이전 버전과 호환이 되는 리펙토링으로 예를 들면 메서드 이름을 바꾸더라도 테스트가 중단 됩니다. 구현 세부 사항을 테스트 하기 때문에 이런 테스트들이 실패를 하게 됩니다. 요약하면 인스턴스나 상태 값을 테스트 한다는 것은 사용자가 알지도 못할 뿐더러 신경쓰지 못하기 때문에 테스트가 주는 자신감과 점점 멀어지게 됩니다.

낭비처럼 보이는 것에 대해서

속도에서는 크게 느껴지지 않을 정도의 차이가 납니다.

실제 단위 테스트를 위해서

일반적으로 얕은 렌더링은 다른 컴포넌트를 렌더링 하지 않습니다. 이 때문에 내부 다른 컴포넌트로 인한 애플리케이션이 중단 될 수있는 위험을 감지 하지 못한다는데 단점이 있을 수 있습니다. 테스트가 진행되는 컴포넌트는 의도한 대로 움직일 순 있지만 오류를 유발하는 새로운 종속성이 도입 됬을때 해당 테스트가 보장 될 수 없다는것을 의미합니다. 오류가 발생하는 하위 컴포넌트가 들어와도 테스트 컴포넌트가 테스트 의도 대로 움직인다면 테스트 시점에서 응용 프로그램이 제대로 작동하리라는 확신을 할 수 있습니까?

누가 어플리케이션이 제대로 동작하지 않는데 단위 테스트에 신경을 쓰겠습니까? 어플리케이션이 제대로 동작하지 않을때는 내가 사용하고 있는 서드 파티 컴포넌트가 나의 시스템 행위를 깨트렸는지를 확실히 알고 싶을 것입니다.

무거운 통합 테스트에 좀더 의존하는 것이 유닛 테스트를 더 적게 필요로 하고 컴포넌트에 대한 엣지 케이스에 대한 유닛 테스트만 필요로 하게 됩니다. 이러한 상황에서도 어떤 구성요소가 mock이 되었고 그것들이 모두 렌더링이 된다는 것을 확신할 때 유지 관리 가능한 테스트 베이스로 이어질 것입니다.

테스팅 작성시 중첩을 피하자

가장 Root describe에 변수들을 설정 해두고 각 중첩된 자식 describe 에 beforeEach 를 사용하면서 해당 변수에 그때 그때 마다 다른 테스트 변수들을 할당해서 테스트를 하지 맙시다. 이렇게 작성하게 되면 나중에 실제 테스트 코드를 살펴 볼때 변수를 추적하기 위해서 시간을 많이 소비 해야 합니다. 변수를 계속 재 할당하는 것은 안티 패턴에 속하고 피해야 할 것입니다. 변수를 계속 재 할당하는 것이 아닌 공통 설정을 할 수 있는 방법을 찾아 봅시다.
잘못된 추상화를 방지하기 위해서 가장 쉬운 방법은 각 테스트 마다 인라인 방식으로 넣는 것 일 겁니다. 중복되는 코드가 보일지 몰라도 이 테스트들을 살펴 보기에는 더 명확할 것입니다. 각 테스트에서 진행되는 작업을 이해하기가 더 편리합니다.
Apply AHA (Avoid Hasty Abstractions) 급한 추상화를 피해서 작성 해야 합니다. 잘못된 추상화보다 중복을 먼저 선호하고 변화하는 것에 대해서 최적화를 해야 합니다. 하지만 중복되는 코드에 대해서 줄이고 싶다면 테스트 간에 코드를 공유할 수 있어야 합니다. 다시 beforeEach 카드를 집어 든다면 다시 변수를 재 할당해야 하는 수를 생각 해야 하기 때문에 선호 하지 않습니다. 이럴 때 함수를 사용 할 수 있습니다.

describe 로 테스트 파일이 커질 때 시각적으로 테스트를 그룹화 시킬 수는 있지만 테스트 파일이 커지는 것을 좋아하지 않습니다. 대신 파일별로 나눠서 그룹을 만드는 것을 더 선호합니다.

beforeEach/afterEach/etc 이밖의 유틸리티를 나쁘다고 하는 것은 아닙니다. 테스트 안에서 가변 변수의 사용을 주의 해야 한다는 것입니다.

테스트를 위해 글로벌한 환경을 일부 변경해야 하는 경우가 있습니다. 이럴땐 정리를 해야 하는 상황이 생깁니다. @testing-library/react@9 환경에서는 자동으로 테스트 하나가 끝나면 cleanup 을 진행합니다.

정리

E2E 방식으로 테스트를 진행하는 법이 사용자가 기능을 경험하는 방식이므로 선호되는 방법입니다. 만약 자식 컴포넌트에 부모 컴포넌트에서 넘겨주는 props 기능이 아닌 자체적으로 들고 있는 기능이 있다면 자식 컴포넌트에 별도로 테스트를 진행하는 것이 좋을 거 같습니다.

테스트를 작성할 때 세부적인 구현에 포커싱을 맞추지 않고 컴포넌트를 리펙토링 했을때 테스트가 깨지지 않게 하는 것이 목표로 삼아야 할 것입니다. 해당 컴포넌트의 구현에 대한 테스트가 아닌 기능에 대해서 테스트를 진행하는 것입니다. 즉, 테스트는 구현이 어떻게 상세로 되어 있는지 알 필요가 없는 것입니다. 또한 실제 사용자들이 겪을 만한 것들에 대해서 테스트를 진행하는 것이 테스트를 유지 관리하기가 더 편리 할 것으로 생각이 됩니다.

여기서 구현이라 하면 인터페이스의 메서드 이름대로 실제 동작하는 코드를 작성하는 것이라고 할 수 있고, 기능은 인터페이스의 메서드 이름 정도 생각하면 될 듯 싶습니다. 코드 하나 수정할 때마다 test case가 같이 수정이 되는 것이 아닌 오랫동안 유지 될 수 있는 test case를 만들려는 노력을 해야 할 거 같습니다.