1.서론
테스트 주도 개발(Test-driven Development: TDD)은 요구사항 수집이나 모델링을 수행하기 전에 테스트 케이스를 먼저 작성하는 방법이다. 테스트 주도 개발에 대한 연구 결과에 의하면 테스트 주도 개발은 시스템의 품질을 높여주고 생산성을 향상시킨다.
TDD는 어째서 동작하는 것일까? 어떻게 테스트가 개발을 주도할 수 있을까? TDD가 겉보기에는 단순해 보이지만 여기에는 소프트웨어 개발에 대한 독창적인 사상이 숨겨져 있다. TDD를 이해하기 위해서는 소프트웨어 개발이 무엇인지 다시 생각해 보아야 한다.
2.기존 개발 방식에 대한 검토
요구사항이 확정된 후 확정된 요구사항을 반영하여 개발한다. 요구사항은 확정될 수 있는가? 요구사항이 프로젝트가 끝날 때까지 변경된다는 것은 분명하다. 우리는 고객을 통제할 수 없기 때문에 요구사항도 통제할 수 없다. 요구사항을 통제하고 확정하는 것이 불가능하다면 우리는 언제 개발에 들어가야 하는가?
또 한가지 문제는 요구사항이 확정됐다고 해서 요구사항이 명백해 졌다는 것은 아니다. 요구사항은 항상 모호하다. 그리고 큰 요구사항이 확정되었지만 그 요구사항을 충족시키기 위한 하위 요구사항은 확정된 것이 아니다. 요구사항이 확정 불가능하고 모호하다면 요구사항이 개발을 주도할 수 없다.
요구사항이 확정되지 않았다면 무엇을 테스트하는가?
모든 개발자는 요구사항이 불분명한 상태에서 개발에 들어간다. 그렇다면 무엇을 테스트해야 하는가? 요구사항이 확정되지 않았다면 무엇이 맞는 것이고 무엇이 틀린 것인지 알 수 없다. 따라서 개발이 불분명해지는 만큼 테스트는 더 불분명해진다.
테스트는 언제 완료되는가?
요구사항의 불분명함 때문에 개발조차 언제 완료될 지 불분명하다면 테스트의 완료시점은 더욱 불분명해진다. 우리는 테스트의 종료시점을 정할 수 없다. 실제 프로젝트에서도 테스트는 가장 마지막 부분에 이루어진다. 설사 테스트하여 오류 목록이 나왔더라도 오류를 잡을 시간은 없다. 따라서 기존 방식의 테스트는 거의 효과가 없다.
위의 그림을 보면 테스트를 진행하면 오류 목록은 쌓이지만 테스트가 출시 바로 전에 수행되기 때문에 오류를 수정할 여유가 없이 제품이 출시된다는 것을 보여준다.
3.TDD의 본질
TDD에서는 프로그램은 업무에 대한 이론이라고 본다. 테스트는 이 이론을 걸러내는 장치이다. 테스트는 이론을 구상하기 전에 먼저 확정되어야 한다. 개발자는 프로그램을 작성하는 것이 아니라 테스트를 통과할 수 있는 이론을 만들어낸다. 테스트를 통과하지 못하면 프로그램은 버려야 한다. 따라서 TDD는 테스트에 대한 기법이 아니라 개발 방식에 대한 이론이다.
테스트를 통과했다고 해서 이 프로그램이 업무를 반영하고 있다고는 볼 수 없다. 그러나 테스트를 통과하지 못하면 이 프로그램은 올바른 이론이 아니기 때문에 버려야 한다.
테스트를 통과하지 못한 이론은 포기해야 하지만 테스트를 통과한 이론의 상태는 모호해진다. 이 이론이 맞다는 보장은 없다. 테스트를 통과한 프로그램은 어떻게 될까? 우리는 프로그램을 보고 다시 현상을 관찰한다.
그리고 다시 새로운 사실을 추가한다. 프로그램은 다시 테스트된다. 테스트를 통과하지 못한 이론은 다시 포기해야 하고 프로그램은 지금까지의 테스트 케이스를 반영하기 위해 처음부터 다시 작성되어야 한다. 이 과정은 다음과 같다.
현상 관찰->사실 확정->이론 구성->테스트->현상관찰
이 과정은 계속 반복될 것이며 이론은 계속 포기하고 다시 작성될 것이다.
이론은 계속 포기하고 재구축된다. 따라서 프로그램도 이렇게 포기하고 재구축하는 과정을 반복해야 한다.
4.전통적인 개발 방식 중 버려야 할 것
TDD를 따르려면 우리는 전통적인 프로그램 개발 방식 중 몇 가지는 포기해야 한다.
-업무 분석이 끝난 후 개발하는 것: 우리가 고찰한 것에 의하면 분석과 개발은 분리되지 않으며 함께 발전한다.
-업무 분석가와 개발자를 분리하는 것: 바람직하지 않다. 분석가와 개발자가 한 팀이라면 괜찮지만 가장 좋은 방법은 개발자가 업무 분석을 하는 것이다.
-폭포수 모델: 폭포수 모델은 소프트웨어의 특성을 전혀 반영하지 않은 잘못된 모델이다.
5. 작성한 프로그램 지우기
여기에서 이론의 포기가 무엇을 의미하는지 생각해 본다. 이론의 포기는 말 그대로 그 동안 작성했던 프로그램을 지우는 것이다. 이것은 refactoring과는 다르다. refactoring은 기존의 사고방식을 포기하지 않고 변형시키는 것으로 매우 위험할 수 있다.
프로젝트의 초기 단계에서는 refactoring보다는 재 작성이 바람직하다. 프로그램을 포기하지 않으면 기존의 이론을 붙들고 테스트를 통과할 수 있도록 기교를 부릴 것이다. 이것은 우리가 원하는 것이 아니다. 기존의 틀을 유지하려 하면 우리는 기존의 사고방식을 포기하지 않겠다는 것이고 프로그램은 스파게티가 되어 버린다.
6.TDD를 실천한 결과
TDD가 결코 쉽지 않지만 소프트웨어 자체의 내재적인 특성 때문에 이 방식이 올바르다는 것을 명확하다. TDD를 수행해 본 결과 다음과 같은 사실을 알 수 있었다.
첫째, TDD를 수행하면 개발자가 업무 지식 면이나 개발 스타일 면에서 성장한다.
둘째, 처음에는 재구축 과정이 느리지만 시간이 지날수록 점점 빨라진다.
세번째 별도의 테스트 기간과 버그 수정 기간이 사라진다. 프로그램을 재구축하는 과정에서 오류 수정이 자연스럽게 이루어진다. TDD가 자연스럽게 품질을 보장하는 것이 TDD의 좋은 점이다.
위의 그림을 보면 오류가 생기는 즉시 코드가 수정되기 때문에 프로그램의 품질이 향상된다는 것을 알 수 있다.
7.TDD를 실천하기 위해 해야 할 일들
TDD를 실천하기 위해서는 다음과 같은 것을 실천해야 한다.
-첫째, TDD는 프로그램을 포기하고 재구축할 것을 요구한다.
-두번째, 개발자의 역할을 바꾸어야 한다. 개발자가 능동적으로 업무 분석에 참여하지 않으면 TDD는 진행되지 않는다.
-세번째는 심리적으로 자신이 만든 결과물을 포기하는 것이 쉽지 않다는 것이다. 그러나 훈련을 통해 극복할 수 있다.
-네번째는 개발자는 테스트 케이스를 작성할 수 있도록 훈련시켜야 하고 업무 분석가는 모호한 모델링이 아닌 테스트 케이스를 분석의 결과로 도출하도록 훈련시켜야 한다.
-다섯째, 처음부터 개발한다. 분석, 설계, 개발 과정을 포기하고 짧은 (최대 2주) iteration을 두어 개발을 처음부터 시작해야 한다.
-여섯째, 개발자에게 업무를 고민할 충분한 시간을 확보해 주어야 한다. 이를 위해 불필요한 문서 작업, 사무적인 작업, 회의는 모두 줄여야 한다.
-일곱째, PM의 관리스타일의 변화를 요구한다. PM은 고객이 개발자에게 직접 일을 주지 못하도록 버퍼를 만들어야 한다. PM과 PL이 주로 해야 할 일은 개발자를 보호하는 것이다.
-여덟째, TDD를 유도할 수 있는 개발 환경을 구축해야 한다. refactoring, 자동 빌드, 자동 테스트를 지원하는 툴을 제공해야 한다.
8. 결론
TDD는 개발 방식의 문제이며 개발자에게는 개발 스타일의 변화를 요구하며 분석가는 개발 능력을 요구한다. 또한 프로젝트 관리자는 개발자의 도메인 지식이 성장하고 설계 능력이 향상되도록 유도해야 한다. 즉 모든 면에서의 변화를 요구한다.
TDD를 적용하기 위해서는 좋은 툴이 있어야 한다. 이 개발툴은 프로그램의 전체 구조를 쉽게 파악할 수 있도록 도와줘야 한다. 재구축을 빨리 진행할 수 있는 개발툴이 있어야 한다. 어느정도 스킬이 쌓이면 refactoring을 할 수 있어야 한다.
또한 테스트 케이스는 빌드 시점에서 자동으로 테스트를 수행할 수 있어야 한다. 오픈 소스 툴을 이용할 수 있으나 프로젝트에서 셋팅하여 사용하려면 전문 인력이 투입되어야 한다. Microsoft Team Foundation Server는 전문 인력의 투입을 최소하면서 프로젝트에서 유연하게 적용할 수 있는 툴이다. 그러나 TDD를 적용하기 위해서는 개발 인력에 대한 충분한 훈련 기간(최소 6개월 이상)이 필요하다.
[원문 다운받기]
|
