요즘 소프트웨어 개발 방법론 중에 많이 쓰고 있다는 TDD에 대해서 궁금한 것도 있었고, 도입하고자 하는 근거를 찾고 싶었다. 그래서 켄트백의 테스트 주도 개발방법론 책과 여러 블로그 글들을 참고해보면서 간략하게 정리해보고자 한다.
TDD란?
소프트웨어 개발 방법론 중에 하나이며, 테스트 → 개발 → 리팩토링 → 테스트 와 같은 짧은 개발 사이클은 반복해나는 방식을 말한다. 기존에는 개발후 테스트 코드를 작성하는 방식이지만, 그 반대로 테스트코드를 먼저 작성한 뒤에 코드를 개발하는 방식이다.
TDD를 통한 개발방법
- Red : 실패하는 테스트 케이스를 먼저 작성한다. 이 단계에서 개발자가 원하는 결과에 대해 명확하게 정하는 단계이다.
- Green : Red단계에서 정한 테스트를 통과하는 가장 간단하게 구현하는 단계이다. 우선적으로 테스트를 통과하는 코드를 작성하는 데 초점을 맞춘다.
- Refactoring : 이미 통과된 Green단계에서 코드의 가독성, 구조, 성능 등을 개선하는데 집중하는 단계이다. 코드의 품질을 향상 시키는 단계이다.
위와 같은 방법들의 사이클을 계속 돌려가면서 이전 단계보다 더 품질 높은 소프트웨어가 탄생하는 것이다.
장점
- 최적화된 코드 생성을 만들 수 있다.
- 개발자가 고객의 요구사항에 대한 명확성을 요청하는데 도움이 된다.
- 새로운 기능을 추가하고 테스트하는데 장기적으로 좋다.
- 처음부터 각 기능에 대한 테스트를 수행하므로 테스트 커버리지가 높다
- 생산성을 높이고 유연하고 유지보수하기 좋은 코드베이스 개발로 이루어진다.
- 반복적인 리팩토링을 거쳐서 빠른 피드백을 제공해준다.
단점
- 초기 개발 단계의 시간이 많이 걸린다.
- 단발성 개발프로젝트에는 부적절하다.
적합한 예시
- 정기적인 피드백을 요구하는 애자일 방식
- 확장성과 지속적인 개발을 요구하는 장기 프로젝트
- 비용 및 기능 측면에서 최적화해야 하는 프로젝트
결론
테스트 주도개발은 red, green, refactoring 단계로 수행되며, 코드 품질과 장기적으로 새로운 기능들을 확장 및 변경하는 프로젝트일수록 큰 진가를 발휘한다. 그리고 반복적인 리팩토링으로 빠른피드백을 제공한다. 하지만 무조건 사용해야 하는 부분은 아니라고 생각한다. 비교적으로 코드품질이 별로 중요하지 않거나 시간이 촉박할 때는 오히려 배보다 배꼽이 더 큰 것 같다. 새로운 방법들을 알아가는 것도 중요하지만 적합한 조건들을 미리 생각해보면서 시기에 맞게 적용을 해야 한다고 생각한다.
References
I'm a web developer.