TDD(Test Driven Development) 관련 내용 정리

TDD(Test Driven Development) 관련 내용 정리

테스트의 중요성

---

 버그는 일찍 발견할 수록 (시간적, 경제적)비용이 적게 든다. 게다가 내가 직접 버그를 발견한 경우가 아니라면(예를들면, QA가 발견할 경우) 비용은 더욱 커지게 된다. 내가 만든 소스코드라도 한참이 지난 후에 다시 보면 코드의 동작 의도가 잘 보이지 않기 때문이다.

 한편, 테스트를 중요시하지 않는 개발자는 프로그램을 완성한 후 힘들게 문서를 작성하고 주석을 단다. 하지만 이는 시간이 지나면 낡은 내용이 되어버린다.(문서화와 주석달기가 중요하지 않다는 뜻이 아니다.) 반면, 잘 작성된 단위테스트는 특정 라인의 코드가 어떤 역할을 하는지 나타낼 수 있다.

TDD에 대한 개요

---

 테스트 주도 개발(Test Driven Development. 이후로는 TDD로 칭함.)은 이름에서 유추할 수 있듯 테스트를 중요시하는 개발 방법론이며, 프로그래밍 전에 테스트 코드를 먼저 작성하는 특징이 있다. 애자일(Agile)방법론과 연관이 깊다.

 

 폭포수 모델로 대표되는 전통적인 개발 방법론은, 구현할 소프트웨어의 규모가 커지고 복잡해지면서 한계에 부딪히게 되었다. 일반적인 공학론적 방법론으로는 소프트웨어의 높은 유동성과 낮은 예측성에 대처하기 힘들었다. 그 이유는 계획과 문서에 크게 의존하고 있기 때문이다.

  익스트림 프로그래밍(Extreme Programming. 이후로는 XP로 칭함.)은 애자일 방법론 중 하나인데, 미래(앞으로 만들어질 소프트웨어의 구성 및 이를 완성할 일정)에 대한 예측을 최대한 하지 않고, 지속적으로 프로토타입을 완성한다. 이 방법론은 추가 요구사항이 생기더라도, 그때그때 추가할 수 있다.

 결국 TDD는 XP를 실천하기 위한 방안 중 하나이다.

▶ TDD의 Life Cycle

TDD의 특징

---

 개발이 모두 이루어진 후, 그것이 계획대로 완성되었는지 테스트 케이스를 작성하고 테스트하는 것이 기존의 방식이다. 이 방식의 단점은 테스트 도중 원하는 값이 나오지 않을 때, 심할 경우 소프트웨어 디자인을 수정해야할 수도 있다.

 하지만 TDD는 테스트 코드를 작성한 이후 코드를 작성한다. 그래서 설계 단계에 프로그램의 목적을 반드시 명확하게 정의해야한다.(테스트를 하면서 "맞다! 깜빡하고 이걸 안했네..." 하면서 코드를 다시 수정하는 일을 줄일 수 있다.)

TDD의 장점 및 단점

---

장점

 1. 재설계 시간을 단축하여 높은 품질의 소프트웨어를 보장한다.

 2. 추가 요구사항 반영이 비교적 쉽다.

 3. 에러 및 버그가 적다.

단점

 1. 낮은 생산성(테스트코드를 추가적으로 개발해야 하므로)

 2. 잘못 설계된 애플리케이션이 될 수 있다.(테스트 디자인부터 설계가 어긋날 경우)

끝으로..

---

 사견을 마지막에 붙여보자면... 우리나라 IT 생태계가 외부 발주 위주의 SI 형태로 돌아가므로, TDD의 도입은 요원한 것 같다. 우리나라의 SI 프로젝트에서는 소프트웨어의 품질보다 납기일 준수가 훨씬 중요하기 때문이다.

 게다가 TDD를 도입하려면 객체지향에 대해 이해도가 매우 높은 개발(혹은 테스트)리더와 개발자들에 대한 교육(TDD는 생소할 테니까..)가 필요하다. 전자가 만족되더라도 고객들은 후자를 만족시켜주기 위해 기다려줄리가 없다.

-끝-

참고및출처

http://www.hoons.net/Lecture/View/644

https://www.slideshare.net/hoonsbara/tdd-41738171

https://ko.wikipedia.org/wiki/

아래의 '공감' 버튼 클릭은 포스팅에 큰 힘이 됩니다.^^