유닛 테스팅이란?
개발적인 측면에서, 유닛 테스팅이라는 개념이 익숙한 분들도 계실꺼고, 그렇지 않는 분들도 계실 겁니다.
유닛 테스팅이란, 소프트웨어를 기능별로 쪼개고, 그리고 그 기능 내부에서 사용되는 함수들도, 쪼개고 쪼개서 아주 작은 단위로 테스팅을 하는것을 의미합니다.
우리의 일상에 비유하여 "홍차 끓여 마시기" 를 테스트 하기 위해서, 전체적인 작업을 하나로 보면서 하는게 아니라 다음과 같은 흐름처럼:
- 물 끓이기
- 티포트와 찻잔에 뜨거운물을 부어 데우기
- 찻잎 놓기
- 차 우리기
- 찻잔에 차 따르기
작업을 하나 하나 나눠서, 각 작업이 잘 이뤄지는지 확인을 합니다.
우리가 만든 소프트웨어가 제대로 작동을 하는지 테스팅을 하기 위해서, 물론 우리가 직접 조작을 하면서 테스팅을 할 수도 있습니다. 하지만, 프로젝트가 커진다면, 매번 코드를 수정 / 새로 작성할때마다 모든 작업이 제대로 이뤄지는지 사람이 직접 확인을 한다면 매우 비효율적일 것입니다. 빠트리는 것도 있을 것이구요.
이러한 작업을, 사람이 아닌, 기계가 하도록 우리는 테스트 코드를 작성하여 진행 할 수도 있는데요, 이를 테스트 자동화라고 부릅니다.
어떠한 경우에 유용할까?
기존에 유닛 테스팅을 많이 한적이 없었다면, 정확히 이게 어떠한 상황에 유용할지 감이 잘 잡히지 않을 수도 있습니다.
우선, 여러분들이 프로젝트를 다른 사람들과 협업을 하게 되는 경우, 유닛 테스팅은 매우 강력한 역할을 하게 됩니다.
예를들어 여러분이 코드 A, B 를 작성했고, 팀원이 코드 C, D 를 구현했다고 가정해봅시다.
그리고, G 라는 기능을 구현하기 위하여, 코드 A 와 C 가 사용되었다고 가정을 해봅시다. G 기능을 구현하면서, 여러분이 여러분의 팀원이 작성한 코드 C 를 아주 조금 수정했습니다. 코드 C 가 잘 작동하는것을 확인했고, G도 잘 작동하는것을 확인 했는데요, 갑자기 의도치 않게 C 기능이 고장나버렸습니다.
만약에, 유닛 테스팅을 했더라면, C 기능이 고장나버린것을 코드를 작성하고 바로 발견 할 수 있지만, 유닛 테스팅을 하지 않을 경우에는, 어쩌다가 해당 버그를 발견하지 못 할 가능성도 있습니다.
간단한 이야기를 길게 설명했는데, 짧게 정리하자면 다음과 같습니다:
유닛 테스팅은, 내가 작성한 코드가 다른 코드들을 망가뜨리지 않도록, 적어도 우리가 사전에 정의한 상황속에서 보장해줍니다.
유닛 테스팅이 필요하지 않을때도 있다
유닛 테스팅은, 부가적인것이여서, 무조건 해야하는것은 아닙니다. 그리고, 가끔씩은, 아예 하지 않는편이 나을때도 있습니다. 예를들어서, 여러분이 만든 프로젝트가 혼자서 작업하는 것이고, 또 소규모 프로젝트라면, 유닛 테스팅을 하는것은 오히려 진행속도를 늦추게 될 수 있습니다. 하지만 물론, 비록 소규모 프로젝트일 지라도 나중에 커질 가능성이 있다면, 시작 단계부터 해두면 나중에 시간을 많이 아낄 수 있게 될 것입니다.
리액트 컴포넌트 테스팅
리액트 프로젝트 또한, 컴포넌트 단위로 하나하나 테스트 로직을 정해줄 수 있습니다. 리액트 컴포넌트를 테스팅할때는, 주로 다음과 같은 형식으로 하게 됩니다.
- 특정 props 에 따라 컴포넌트가 크래쉬 없이 잘 렌더링이 되는지 확인
- 이전에 렌더링했던 결과와, 지금 렌더링한 결과가 일치하는지 확인
- 특정 DOM 이벤트를 시뮬레이트 하여, 원하는 변화가 제대로 발생하는지 확인
이 튜토리얼에서는 위 3가지 방법을 직접 수행하는 방법에 대해서 알아봅니다.
자! 그러면 시작해봅시다!