티스토리 뷰

개요


개발자라면 한번쯤은 테스트 주도 개발 (TDD)에 대해 들어봤을 것이다. 테스트 위주의 코드 작성으로 알고있는 TDD의 장점과 단점을 살펴보고 대략적인 이해를 주는 것이 본 포스팅의 목적이다. 장/단점에 대한 내용은 hoons.net에 14년도에 작성된 http://www.hoons.net/Lecture/View/644 포스팅을 정리한 내용이다.

 

 

TDD란?


TDD의 개발 흐름도

테스트 주도 개발(Test-Driven Development, TDD)은 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다. 개발자는 먼저 요구사항을 검증하는 자동화된 테스트 케이스를 작성한다. 그런 후에, 그 테스트 케이스를 통과하기 위한 최소한의 코드를 생성한다. 마지막으로 작성한 코드를 표준에 맞도록 리팩토링한다. 이 기법을 개발했거나 재발견 한 것으로 인정되는 Kent Beck은 2003년에 TDD가 단순한 설계를 장려하고 자신감을 불어넣어 준다고 말하였다.   - 출처: 위키백과

위에서의 말 처럼 TDD란 테스트 코드를 먼저 작성하고 그에 통과하기 위한 코드를 작성하는 방식의 개발 방식을 말한다. 켄트백이 굳이 이러한 방식을 권장하는 이유가 뭘까?

 

 

TDD의 장점


가장 큰 장점은 높은 퀄리티의 소프트웨어를 보장한다는 것이다. 그렇다면 높은 퀄리티의 소프트웨어는 어떻게 정의할 수 있을까? 참고한 포스트에서는 이를 아래와 같이 3가지로 정의했다.

 

  1. 절대 에러나 버그가 없을 것.
  2. 추가적인 요구사항이 있을 때 손쉽게 그 요구사항을 반영할 수 있을 것.
  3. 유지보수에 용이할 것.

TDD는 아래와 같은 특징 때문에 위 3가지 사항을 모두 만족시킨다.

 

보다 튼튼한 객체지향적인 코드생산 💥 :

TDD는 코드의 재사용성을 보장할 것을 명시하므로 TDD를 통한 소프트웨어 개발 시 기능 별 철저한 모듈화가 이뤄진다. 이는 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하며 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치지 않게된다.

재설계 시간의 단축 💦 :

TDD는 테스트 코드를 먼저 작성하기 때문에 내가 지금 무엇을 해야하는지 분명히 정의하고 개발을 시작하게 된다. 또한 테스트 시나리오를 작성하면서 다양한 예외상황에 대해 생각해 볼 수 있으며 이는 완성도 높은 설계로 이어진다. 따라서 매우 크리티컬한 예외상황이 생길 확률이 극히 낮으며, 개발진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있다.

디버깅 시간의 단축 🔆 :

이는 통합 테스팅이 아닌 유닛 테스팅을 하는 이점이기도 하다. 우리는 각각의 모듈 별로 테스트를 자동화 할 수 있는 코드가 없다면 특정 버그를 찾기 위해서 모든 레벨의 코드들을 살펴봐야 한다. 예를 들어 사용자의 데이터가 잘못 나온다면 DB의 문제인지, 비지니스 레이어의 문제인지 UI단의 문제인지 실제 모든 레이어들을 전부다 디버깅 해야하지만, TDD의 경우 자동화 된 유닛테스팅을 전재하므로 특정 버그를 손 쉽게 찾아낼 수 있다.

테스트 문서의 대체가능 📑 :

주로 SI 프로젝트를 진행하다 보면 어떤 요소들이 테스트 되었는지 테스트 정의서를 만들곤 한다. 이것은 단순 통합테스트 문서에 지나지 않는다. 즉, 내부적인 하나하나의 로직들이 어떻게 테스트 되었는지 제공할 수 없다. 하지만 TDD를 하게 될 경우 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있다.

추가 구현의 용이함 ✏ :

개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드들에 어떤 영향을 미칠지 모른다는 점이다. 따라서 단순한 기능이라도 추가 된 후에는 모든 기능들을 처음부터 테스트 해야한다. 하지만 TDD의 경우 자동화된 유닛 테스팅을 전재하므로 이러한 테스트 기간 역시 획기적으로 단축시킬 수 있다.

 

TDD는 위와같이 무수한 장점을 가지고 있지만 모두가 이 개발 프로세스를 따르지 않는다. 이유가 무엇일까?

출처: https://pixabay.com/ko/vectors/%EB%82%A8%EC%9E%90-%EC%9E%91%EC%97%85-%ED%95%A0-%EB%AC%B4%EC%97%87-%EB%AC%BC%EC%9D%8C%ED%91%9C-311326/

 

TDD의 단점


예상했겠지만 가장 큰 단점은 바로 생산성의 저하다. 단순한 어플리케이션을 개발하는 경우 경험에 의해 어떤 예외상황이 발생할지 눈에 뻔히 보이는 경우가 많다. 특히 이러한 단발성 개발은 개발 기간이 타이트하게 잡히는 경우가 많은데, 이럴 때 TDD를 적용해 뻔한 테스트 코드를 작성하고 그에 통과하기 위한 코드를 작성한다면 마치 답을 알고 푸는 문제집처럼 따분하고 비효율 적일 것이다.

 

본 포스팅에 참고한 박경훈 님의 글에 의하면 아래와 같은 경우도 있다고 한다.

TDD로 프로젝트를 진행하면서 어려운 예외가 생길 수 있는데 그것 때문에 고민하는 순간이 찾아오게 된다. 원칙을 깰 수는 없고 꼼수가 있기는 한데 그 꼼수를 위해서 구조를 바꾸자니 이건 아무래도 아닌 것 같고, 테스트는 말 그대로 테스트일 뿐 실제 코드가 더 중요한 상황인데도 불구하고 테스트 원칙 때문에 쉽게 넘어가지 못하는 그런 경우다.

필자가 현재 몸담고 있는 팀은 해오던 것 들을 조금씩 진화시켜 더 잘할 수 있도록 연구/개발을 진행하고 있고, 코드상이 아닌 하드웨어적 혹은 네트워크 환경에 의한 이슈가 주로 발생하므로 TDD를 적용하지 않고있다. 그 때문인지 주변에서 TDD를 적극 추천하고 활용하는 개발자를 보지 못했다.

 

 

마치며


범용 서비스 플렛폼이 주를 이루는 스타트업쪽에서는 다양한 유저 인풋에 대한 예외상황에 대비해야 하므로 TDD 개발 경험을 우대항목으로 두는 회사가 많다. 따라서 스타트업 취업을 목표로 하고있는 개발자라면 TDD를 활용한 개발을 경험해보는 것이 도움이 될 것이다.

 

필자는 팻프로젝트에 TDD를 녹여내기 위해 켄트백의 저서 테스트 주도개발 을 읽고있다. 많은 분들이 입문용으로 추천해주는 도서이니 만큼 관심있는 독자라면 한번 읽어보길 바란다.

 

 


 

Reference

- https://gmlwjd9405.github.io/2018/06/03/agile-tdd.html
- http://www.hoons.net/Lecture/View/644
- https://ko.wikipedia.org/wiki/테스트_주도_개발

 

 

 

 

 

 

댓글