Test Driven Development
테스트 주도 개발이란?
테스트가 개발을 이끌어 나간다는 뜻으로, 보통은 프로그래밍이 끝난 후에 테스트를 하지만 이 순서를 바꾸어 테스트 케이스를 먼저 작성하고 프로그래밍하는 방식입니다.
개발자는 먼저 요구사항을 검증하는 자동화된 테스트 케이스를 작성한다.
그런 후에, 그 테스트 케이스를 통과하기 위한 최소한의 코드를 생성한다.
마지막으로 작성한 코드를 표준에 맞도록 리팩토링한다
실무에서 프로젝트를 진행할 경우 때로는 요구 사항이 명확한 기획을 전달받는 반면, 명확하지 않은 요구 사항을 전달받는 경우도 있습니다. 이런 경우에 충분히 검증하지 않고 작업을 하게 되면 기획 내용이 수시로 변경될 가능성이 큰데 그것은 곧 지저분한 코드를 만들기에 딱 좋은 조건이 되어버립니다.
저 같은 경우엔 앞서 말씀드린 명확하지 않은 요구 사항을 지저분한 코드로 개발한 경험에서 지옥 같은 유지 보수를 몇 번 경험해 보았었는데요, 첫 단추가 중요하다고 유지 보수하는 기간이 길어질수록 점점 더 힘들어지고 자신감도 떨어지게 되는것 같아서 TDD는 정말 중요한 부분이구나 뼈저리게 느꼈죠 ㅎㅎ
처음에는 테스트케이스를 작성하는 게 더 번거롭게 느껴지기도 했었지만, 악순환의 반복보다는 훨씬 편하고 코드도 깔끔하게 나오면서 자신감도 생기는 것 같습니다.
TDD를 적용뿐만 아니라 테스트 코드 자체가 없는 프로젝트를 진행했다고 생각하면, 백엔드 애플리케이션의 크기가 매우 커졌을 때 node의 버전을 최신 버전으로 업데이트하거나 전체 시스템에 영향이 있을법한 부분들을 수정했다고 했을 때 큰 불안감으로 다가올 것입니다.
테스트 코드는 함수같이 특정 기능의 단위 테스트, 사용자의 입장에서 테스트하는 E2E(End To End) 테스트 등이 있습니다. 이 부분은 다음 포스팅에서 자세히 다루겠습니다.
TDD 사이클
1. 요구사항 파악
2. 테스트 코드 작성
3. 테스트 코드가 돌아가도록 실제 코드 작성
4. 리팩토링
TDD의 장단점
장단점에 대해서는 많은 분들이 생각이 다른 것 같습니다.
1. 개발 시간이 더 길어진다
: 시작부터 2개의 코드를 작성해야 하기 때문에 아무래도 초기 비용은 더 큰 것 같다고 생각합니다. 또 익숙하지 않은 상태라면 더욱 그렇겠죠.
2. 결함이 줄어든다.
: SW를 개발하면서 예상하지 못했던 시간을 많이 소요하는 것은 대부분이 버그 때문일 것입니다. TDD를 적용하면 통상적으로 결함이 1/2 ~ 1/10 정도 줄어든다고 하니, 이 부분만 생각해도 1번의 단점은 이겨냈다고 생각합니다.
3.깨끗한 코드로 유지 보수 비용이 낮아진다
: 같은 기능을 추가한다고 할 때, 아무래도 깨끗한 코드보다 지저분한 코드에서 작업하는 게 작업시간이 훨씬 오래 걸리겠죠?
이미지 출처 : https://marsner.com
