테스트 주도 개발이란?
전통적인 프로그램의 개발방식을 살펴보자. 흔히 얘기하는 폭포수 방식 모델이다. 그리고 현 다니고 있는(2020.12월 기준, 곧 이직 예정) 웹에이전시에서는 이런 방식을 따르고 있고 아마 단기 납품에 집중되는 회사들은 이 방식을 따르고 있을 것이다.
즉 그림을 보면 알 수 있듯이 위에서부터 계단식으로 점점 떨어져 내려오는 것을 볼 수 있다. 요구사항 및 명세를 작성, 디자인, 구현, 테스팅, 유지보수까지 내려오게 되며 이 단계는 순차적으로 진행되어야 한다.
문제는 현실세계의 프로젝트는 이렇게 아름답게 진행되지는 않는다는 것이다.
발주 요구를 한 클라이언트의 개발관련 이해도는 그닥 높지 않을 뿐더러 중간에 요구사항이 바뀌는 건 수십번, 그럴때마다 기획서는 업데이트를 진행해야 하며, 변경사항이 어떻게 나올지 모르는 상황에서 개발자는 대기할 수 밖에 없고 납품기한은 정해져있다면 백퍼센트 울면서 야근하게 된다.
이 방법론에 대한 대안으로 현재 대세인 TDD가 나오게 된다.
요지는 작은 단위의 테스트 케이스를 작성해나가면서 전체 프로젝트를 완성해나가는 것이다.
왜 테스트주도 개발을 해야하는가?
- 코드 유지보수에 효과적
프로그램을 하나 만들때 사실 정작 시간이 많이 들어가는 부분은 이미 짜여진 코드를 디버깅, 최적화하거나 기능을 추가하는 부분이다. 테스트코드를 미리 만들어둔다면 다른 코드의 품질을 보증할 수 있으므로 리팩토링에 매우 용이하다. - 작성해야 하는 코드에 대한 명확한 이해
솔직히 얘기해보자. 일단 무의식적으로 키보드부터 치고 있지는 않은가? 내가 무슨 코드를 짜고 있었지? 하다가 갑자기 지저분한 코드가 보이고 이를 고치고.. 갑자기 다른 컴포넌트쪽의 기능도 어차피 필요하기 때문에 여기도 손대고..
이렇게 하는 것보다 테스트 코드로"아 내가 이 테스트 코드를 작성하고 있으니 여기에 집중해야지"라는 생각을 할 수 있다.
또한 이렇게 함으로써 로직이 머릿속으로 그려지고 실제 코드를 작성할 때 깔끔하게 작성할 수 있다. - 그 자체가 하나의 문서가 될 수 있다. 단위테스트를 진행할때 테스트문서만 보더라도
"아 이걸 만든 개발자가 이런방식으로 생각하며 만들어나갔군"이라고 추적해보며 유지보수할 수 있기 때문에 빠른 이해가 가능하다.
단점
- 테스트 코드를 효율적으로 짜야 한다. 중복되는 테스트가 있는지, 혹은 정말 필요한 테스트인지, 상위 테스트에서 이미 다루었던 코드이기 때문에 작성할 필요가 없다던지.. 이는 조직의 테스트코드가 어떻게 이루어지는지 확인하고 리드 개발자가 이끌어가야 할 필요성이 있다.
- 단순한 프로젝트거나, 단기 납품에 집중되는 프로젝트의 경우에는 필요가 적다. 예를 들어보면 가벼운 웹사이트 즉, 5장 이내로 이루어지는 단발성 설문 사이트의 경우 테스트코드가 정말 필요할까?
오히려 빨리 빌드해보고 확인해보는 것이 더 효율적일 수도 있다.
Red , Green , Yellow 테스팅
테스트 코드를 작성할 때는 이렇게 세 단계를 거치게 된다. 왜 이렇게 3단계를 거치게 될까? 이 세단계를 일단 뜯어보면 다음과 같을 것이다. 리액트 테스트 코드를 다음과 같이 짠다고 가정한다.
//App.js
const App = () => {
return <div data-test="app"></div>;
};//App.test.js
test("App 컴포넌트 렌더링", () => {
const wrapper = shallow(<App />);
const appComponent = wrapper.find('[data-test="app"]');
expect(appComponent.length).toBe(1);
});- Red : 일단 테스트 코드를 작성할 때는 실패할 경우의 코드부터 작성한다. 그 이유는 쓰다보면 자연히 알게 되는데, 우선 잘못된 케이스를 집어넣고 실패가 되는 것을 확인해야 제대로 된 작동사항을 점검할 수 있기 때문이다.
- Green : failure가 된 것을 확인한 후 이제 정상작동할때의 코드를 작성한다.
- Yellow : 테스팅 코드를 작성한다고 끝이 아니고, 중복코드를 제거하고 테스팅코드를 유지보수하는 단계라고 할 수 있겠다.
React 테스팅 도구
- react-testing-library: 이 npm 라이브러리는 react팀에서 추천하는 라이브러리이다. 2018년에 출시된 만큼 상당히 새롭지만 js현황조사를 보면 많이 사용하는 도구로 각광받는 듯하다. 줄여서 RTL이라고 부르기도 한다.
- Enzyme: Airbnb에서 만든 테스팅 라이브러리로 위의 react-testing-library보다 더 인지도가 있을지도 모르겠다. 왜냐하면 2015년에 출시되었고 그만큼 문서들도 많다.
차이점은 Enzyme은 Virtual Dom을 테스팅하고 RTL은 실제 렌더링된 DOM을 기준으로 테스트를 작성한다는 점이 아무래도 가장 크다. RTL은 실제로 렌더링된 결과물에 더 중점을 주고 만든 반면, Enzyme은 state와 prop값을 읽어와 이를 테스팅할 수 있는 등, 구현하는 과정에서 내부적으로 어떻게 동작하는지에 집중하는 느낌을 받는다.