-
Notifications
You must be signed in to change notification settings - Fork 5
테스트 전략
| 정적 테스트 | 유닛 테스트 | 통합 테스트 | 스냅샷 테스트 | UI 테스트 | e2e 테스트 | |
|---|---|---|---|---|---|---|
| 정의 | 실제 코드를 실행하지 않고 소프트웨어에 대해 수행되는 테스트 | 소스 코드의 특정 모듈이 의도된 대로 정확히 작동 하는지 검증하기 위한 테스트 | 두 개 이상의 단위가 함께 잘 작동 하는지 확인하는 테스트 | 어떤 기능의 예상 결과를 미리 정확히 포착해두고 실제 결과에 비교하는 테스트 | UI 변화에 따른 시각적인 피드백을 얻기 위한 테스트 | 사용자가 어플리케이션에서 경험할 것으로 예상되는 행동을 코드로 작성해 검증하는 테스트 |
| 역할 | 구문 오류와 타입 오류를 감지해 알려줘서 런타임 에러를 방지 | 비즈니스 로직을 담당하는 모듈을 검증함으로써, 세부적인 확인 가능 | 페이지 단위로 사용자 시나리오 검증 가능 | UI가 예상 밖으로 변경 되는지 확인 가능 | 컴포넌트의 다양한 상태(UI 형태)를 빠르게 검증 가능 | 사용자의 서비스 이용 흐름대로 기능이 정상적으로 작동하는지 검증 가능 |
사용 도구 - ESLint, Stylelint, TypeScript
eslint의 경우 javascript 구문 오류를, typescript를 통해 타입 오류를 감지해 런타임 에러를 사전에 방지할 수 있다. stylelint도 rules 설정을 통해 잘못된 css property 작성을 방지할 수 있다.
이는, 동적 테스트를 수행하기 전에 결함을 발견하고 해결할 수 있으므로 테스트에 필요한 전체 시간을 단축할 수 있다고 판단해 적용하고 있다.
사용 도구 - jest, React Testing Library (RTL)
팀원 들과 함께 고민해보았을 때, 기능에 대한 hook을 넘어 모든 모듈에 대해 테스트 코드를 작성하는 것은 MVP 개발 과정에서 비효율적이라고 생각했다.
사용자 시나리오를 작게 쪼개어 통합 테스트를 하다보면, 자연스럽게 hook에 대한 유닛 테스트를 하게 될 것이라고 생각해 모든 모듈에 대해 필수로 진행하기 보단, 페이지 내에서 사용되는 custom hook에 대해 선택적으로 진행하는 것이 좋다고 생각했다.
사용 도구 - React Testing Library (RTL)
통합 테스트를 통해 페이지 단위로 검증하는 방식으로 진행하는 것이 좋다고 의견이 모아졌다.
unit test의 경우, 스프린트 주기에 맞춰 모든 모듈 들을 테스트 하다보면 기간이 너무 촉박할 것이라고 생각했다.
현재 상황(MVP를 만드는 기간)에서 테스트의 핵심에 대해 의견을 모아볼 때 아래와 같은 항목이라고 생각했다.
<aside> 🧪 테스트 핵심 항목
- 피드백 사이클을 줄여 각 기능에 대해 어떤 테스트 항목이 필요한지 인지한다.
- 사용자 시나리오만 빠르게 검증하여 개발 생산성을 높인다.
- 스프린트 속도가 빨라져도 어느 정도의 문서화가 가능해야 한다. </aside>
이 항목 들에 대해 unit 테스트의 경우 시간 비용이 커진다는 단점이, e2e 테스트의 경우 사용자 관점에서 테스트가 가능하지만, 피드백 주기가 길어진다는 단점이 있다고 생각했다.
페이지에 대한 hook 테스트를 할 경우, 페이지 개발 도중 테스트가 가능하기 때문에 피드백 주기를 줄일수 있고, 어떤 기능이 필요한지 명확히 인지하며 개발할 수 있다.
또한, 사용자 시나리오 대로 테스트 케이스를 만들어 하나의 제품 스펙으로써 관리가 가능하다.
snapshot 테스트의 경우, 컴포넌트의 변경점이 발생했을 때 이전 컴포넌트와 변경된 컴포넌트를 비교하여 변경점이 예상한대로 이뤄졌는지 확인하는 과정이다.
하지만, 현재 상황에서는 변경점 까지 비교하는 과정이 불필요하다고 생각했고, UI 테스트를 통해 다양한 props 조합에 따른 컴포넌트 렌더링 결과를 쉽게 확인하는 정도만 필요하다고 생각했다.
따라서 snapshot 테스트는 진행하지 않는 것으로 의견이 모아졌다.
사용 도구 - StoryBook
hook 테스트를 통해 기능이 정상적으로 작동 하는지 확인하고 있지만, 페이지가 실제 화면에서 잘 보여지는지 확인하는 것도 필요하다고 의견이 모아졌다.
또한, Storybook을 통해 페이지와 컴포넌트들에 대한 다양한 시나리오를 하나의 격리된 공간에서 관리할 수 있다는 장점이 있다. 이를 통해, 스프린트를 진행하며 기능을 구현하거나 변경 하더라도, 문제 없이 동작하는지 직관적으로 확인할 수 있다고 생각해 테스트를 진행하기로 생각했다.
E2E 테스트를 사용하지 않겠다고 결정한 3가지 이유는 다음과 같다.
<aside> 💡 E2E 테스트를 하지 않는 이유
-
E2E 테스트의 경우 사용자 시나리오를 검증해야 하기 때문에, 페이지가 완성된 이후 테스트 코드를 구성하게 된다. 이는, 피드백을 받는 주기를 길게 만든다. 또한 사용자의 흐름에 대해 테스트를 하다보니 호흡이 길어 오류가 발생해도 정확히 어떤 오류가 발생하였는지 피드백을 받기가 어렵다. 이러한 단점들을 모아봤을 때 피드백의 주기가 길어진다는 점이 개발의 효율을 떨어뜨린다고 판단했다.
-
통합 테스트를 진행하면서 사용자의 흐름에 대한 기능 작동을 확인할 수 있다고 판단하여 e2e 테스트 진행을 하지 않는 것이 좋다고 생각했다.
-
google map api를 많이 다루는 투룻 어플 특성상 지도 사용이 빈번하게 등장한다. 이를 e2e테스트를 통해 확인하기 어렵다고 판단하여 해당 테스트를 진행하지 않는 것이 좋다고 생각했다.
</aside>