아래의 내용은 http://www.zdnet.co.kr/ArticleView.asp?artice_id=20090615193506 에서 이종국 님이 집필하신 내용을 카피한 부분입니다. 문제가 될 시 삭제 하도록 하겠습니다.
분석, 설계 기법으로서의 테스트 주도 개발(TDD)
1. 서론
테스트 주도 개발(Test-driven Development: TDD)은 요구사항 수집이나 모델링을 수행하기 전에 테스트 케이스를 먼저 작성하는 방법이다. 테스트 주도 개발에 대한 연구 결과에 의하면 테스트 주도 개발은 시스템의 품질을 높여주고 생산성을 향상시킨다.[1] TDD는 어째서 동작하는 것일까? 어떻게 테스트가 개발을 주도할 수 있을까? 요구사항이 개발을 주도해야 하지 않는가? TDD가 겉보기에는 단순해 보이지만 여기에는 소프트웨어 개발에 대한 독창적인 사상이 숨겨져 있다. TDD를 이해하기 위해서는 소프트웨어 개발이 무엇인지 다시 생각해 보아야 한다. 이를 위해 소프트웨어 개발에 대한 상식적인 생각들을 검토해 보자.
2. 기존 개발 방식에 대한 검토
q 요구사항이 확정된 후 확정된 요구사항을 반영하여 개발한다.
요구사항은 확정될 수 있는가? 요구사항이 프로젝트가 끝날 때까지 변경된다는 것은 분명하다. 우리는 고객을 통제할 수 없기 때문에 요구사항도 통제할 수 없다. 요구사항을 통제할 수 있다는 것은 환상이다. 그러면 요구사항을 통제하고 확정하는 것이 불가능하다면 우리는 언제 개발에 들어가야 하는가? 또 한가지 문제는 요구사항이 확정됐다고 해서 요구사항이 명백해 졌다는 것은 아니다. 요구사항은 항상 모호하다. 그리고 큰 요구사항이 확정되었지만 그 요구사항을 충족시키기 위한 하위 요구사항은 확정된 것이 아니다. 우리가 개발하는 소프트웨어는 큰 분류에서 작은 분류, 복잡한 로직까지 계층구조로 구성된다. 요구사항도 그러하다. 우리가 소프트웨어를 계층적으로 작성하기 위해 요구사항도 계층적으로 작성한다면 우리는 영원히 요구사항을 확정할 수 없고 개발에 들어갈 수 없을 것이다. 이렇듯 요구사항이란 말 이가 확정 불가능성과 모호함을 가지고 있다. 그렇다면 이 요구사항이 개발을 주도할 수 있을까?
q 요구사항이 확정되지 않았다면 무엇을 테스트하는가?
모든 개발자는 요구사항이 불분명한 상태에서 개발에 들어간다. 그렇다면 무엇을 테스트해야 하는가? 요구사항이 확정되지 않았다면 무엇이 맞는 것이고 무엇이 틀린 것인지 알 수 없다. 따라서 개발이 불분명해지는 만큼 테스트는 더 불분명해진다.
q 테스트는 언제 완료되는가?
요구사항의 불분명함 때문에 개발조차 언제 완료될 지 불분명하다면 테스트의 완료시점은 더욱 불분명해진다. 우리는 테스트의 종료시점을 정할 수 없다. 실제 프로젝트에서도 테스트는 가장 마지막 부분에 이루어진다. 설사 테스트하여 오류 목록이 나왔더라도 오류를 잡을 시간은 없다. 따라서 기존 방식의 테스트는 거의 효과가 없다.
위의 그림을 보면 테스트를 진행하면 오류 목록은 쌓이지만 테스트가 출시 바로 전에 수행되기 때문에 오류를 수정할 여유가 없이 제품이 출시된다는 것을 보여준다.
3. 소프트웨어에 대한 사고 방식의 변화
위의 3가지 문제는 소프트웨어의 특이한 성격 때문에 발생하는 문제이다. 다른 산업군에서는 제품을 개발할 때 명확한 요구사항을 기반으로 개발을 진행한다. 그러나 소프트웨어는 언제나 범위가 불분명하고 내용이 모호한 상태에서 개발이 진행된다. 이것은 소프트웨어 개발자가 잘못 행동했기 때문이 아니고 소프트웨어의 성격이 다른 산업군의 제품과는 다르기 때문이다.
소프트웨어는 무엇인가? 소프트웨어는 기계를 동작시키는 명령어의 집합인가? 과거에는 그러했다. 우리가 어셈블러를 사용할 때는 기계의 동작을 잘 알고 있어야 한다. 그러나 프로그램은 점점 추상화되었다. 이제 우리는 업무를 바라보면서 프로그램을 작성한다. 우리의 주 관심사는 업무이다. 업무를 프로그램으로 옮기는 것이다. 즉 이제 소프트웨어는 업무의 전산 기반 모델이다. 더 줄여서 말하면 업무 모델이다. 다시 줄이면 소프트웨어는 모델이다. 모델이라는 말은 현실세계를 설명하는 이론이라는 말이다. 즉 소프트웨어는 업무를 설명하는 이론이다. 이 이론의 밑바탕에는 전산 시스템이 들어 있다. 업무에 대한 이론을 수학을 바탕으로 전개할 수도 있다. 그러나 우리는 컴퓨터에서 동작하는 모델을 만든다. 컴퓨터에서 동작하는 모델은 추상적으로는 유한 상태 기계이기 때문에 우리는 유한 상태 기계를 기반으로 업무에 대한 모델을 만든다고 볼 수 있다. 소프트웨어가 이론이라는 것은 물리학이 시간과 공간, 물질에 대한 모델인 것과 동일하다. 물리학자들은 달의 움직임을 관찰하고 이 움직임을 설명할 수 있는 이론을 만드는 것처럼 개발자들도 업무를 관찰하고 업무에 대한 이론을 만든다.
이론은 언제나 불분명함과 모호함을 특성으로 가지고 있다. 예를 들어 내가 어렸을 때 선생님한테 사과가 땅에 떨어지는 것은 중력 때문이라는 말을 들었을 때 나는 중력이 무엇인지 전혀 이해할 수 없었다. 중력이라는 말을 들었을 때 받았던 느낌은 어떤 거인이 팔을 뻗쳐서 사과를 움켜쥐고 있는 이미지였다. 그리고 왜 달이 지구로 떨어지지 않는지 풍선은 땅에 떨어지지 않고 하늘로 올라가는지 궁금해졌다. 중력을 제대로 이해한 것은 대학에 가서 중력을 수식으로 사용하여 온갖 현상을 계산해 보고 답이 올바로 나온다는 것을 확인한 이후였다. 중력을 이해했다기 보다 '중력이 온갖 현상을 잘 설명하니까 맞는가 보다'하고 더 이상 이해하기를 포기했다. 나는 내가 이해력이 떨어지는 것이 아닌가 고민했는데 사실 최고의 과학자들조차 이론을 이해하는 사람은 없고 단지 그 이론을 현상을 설명하는데 잘 사용하는 것뿐이라는 것을 나중에 알게 되었다.
이렇듯 이론이 현실을 어떻게 설명하는지 배운 후에야 우리는 이론이 무엇인지를 알게 된다. 소프트웨어도 마찬가지이다. 어떤 고객이 "우리 시스템에 들어온 정보는 만일의 사태에 대비하여 삭제하지 않으며 삭제 상태로만 남겨둔다"고 말했다고 하자. 이 말에서 우리 시스템에 들어온 정보라는 것은 고객이 속한 회사의 모든 정보를 말하는가? 아니면 개발자가 개발할 시스템에 들어온 정보를 말하는가? 어쩌면 고객의 말은 과장된 것이고 고객이 하는 업무 중 중요한 부분만 보관해야 한다는 당연한 이야기일 수도 있다. 삭제 상태라는 말도 모호하기는 마찬가지이다. 테스트용 데이터도 삭제해서는 안되는가? 코드성 데이터나 중요한 기초 자료가 잘못들어갔을 경우 데이터베이스에서 강제로 삭제해서도 안되는가?
이렇듯 고객의 요구사항은 그 자체로는 무엇을 의미하는지 모호하다. 이론은 검증을 거쳐야 의미가 분명해진다. 고객의 요구사항도 검증을 거처야 무엇을 의미하는지 알 수 있다. 과학자들도 수많은 실험을 반복한 후에야 이론이 의미하는 바와 이론의 한계, 오류를 깨닫게 된다.
4. 소프트웨어 개발 방식
소프트웨어가 이론이기 때문에 과학자들이 어떻게 행동하는지를 보면 소프트웨어 개발 방식을 재정립하는데 도움을 받을 수 있다.
과학자들은 어떻게 행동할까? 먼저 관찰한다. 관찰의 결과를 기술한다. 예를 들어 태양은 동쪽에서 뜬다. 물은 위에서 아래로 움직인다. 그리고 관찰의 결과를 설명할 수 있는 이론을 구상한다. 이 이론은 가설이다. 가설은 사실과 다른 것이며 상상의 결과이다. 수많은 이론들이 있을 수 있다. 우리는 얼마든지 많은 이론을 만들 수 있다. 그러나 우리가 관찰한 사실들을 설명할 수 있는 이론은 극소수이다. 그리고 과학자가 주장한 이론이 관찰된 사실을 모두 설명하는지 검사한다. 예를 들어 물리학자들은 에너지 보존 법칙을 무시하면 얼마든지 세상을 설명하는 많은 이론들을 만들 수 있다. 그러나 에너지 보존 법칙을 만족하는 이론은 극소수이다. 에너지 보존 법칙을 만족하면서 또 다른 사실들까지 설명하는 이론은 현재 물리학의 이론이 유일하다.
마찬가지로 개발자들도 업무라는 현상을 관찰한다. 그리고 이 업무를 설명하는 모델을 만든다. 그러나 현상을 관찰하는 것만으로는 좋은 모델을 만들 수 없다. 우리는 현상 중에서 명확한 사실을 기록해야 한다. 그리고 이것이 우리가 만들려는 프로그램을 제약한다. 우리가 관찰한 현상을 기록하지 않는다면 프로그램이 관찰한 현상을 만족하는지도 판단할 수 없다. 그런데 기록한다는 것은 단순히 문서를 작성한다는 뜻이 아니다. 우리가 사실을 모호하게 기술한다면 이론도 모호해질 것이다. 사실에 대한 진술은 명확해야 한다. 사실에 대한 진술은 수 많은 이론 들을 판단할 수 있는 근거가 되야 한다. 다음 그림을 보자.
위의 그림에서 체는 사실, 장기는 이론이다. 사실은 이론을 걸러주는 역할을 해야 하는데 사실이 모호하면 틀린 이론도 걸러지지 않을 것이다. 그물을 단단히 짜야 한다. 앞의 예에서 고객이 '우리 시스템에 들어갈 정보'라는 말을 '우리가 개발 시스템에 사용자가 거래용으로 입력하는 정보'라고 말하면 의미가 더 분명해 질 것이다. 따라서 사실은 이론을 검토했을 때 이론에 대해 ‘예’, ‘아니오’로 판단해 줄 수 있을 만큼 구체적으로 작성되어야 한다. 따라서 사실은 이론을 테스트해 줄 수 있는 문장으로 작성되어야 한다. 항상 사실이 먼저이다. 예를 들어 '고객이 상품을 주문할 때 주문 정보가 잘못되어 삭제했더라도 잘못된 주문 정보는 데이터베이스에 삭제 상태로 남아야 하고 데이터베이스에서 조회하면 조회가 되어야 한다.'라고 하면 이 문장은 프로그램을 작성하여 쉽게 테스트 할 수 있다. 그리고 이 사실들을 만족하는 이론을 작성한다.(소프트웨어에서는 테스트를 통과할 수 있는 프로그램을 작성한다.) 그리고 작성된 이론은 사실을 통해 버리든지 채택한다. 만일 잘못된 주문 정보를 화면에서 삭제하고 데이터베이스에서 조회했는데 나오지 않는다면 프로그램을 잘못 작성한 것이다. 이것을 도식으로 표현하면 다음과 같다.
현상->관찰-현상에 대한 진술->이론 구성->현상에 대한 진술을 통해 이론을 버리거나 채택함.
과학자들이 하는 방식은 TDD와 동일하다. TDD도 다음과 같이 진행된다.
업무에 대한 관찰->업무에 대한 테스트 가능한 문장 구성(테스트 케이스)->프로그램 개발->테스트를 통해 프로그램을 버리거나 채택함.
위에서 이론을 채택하거나 포기하는 것이 가장 중요하다. 만일 이론을 버릴 수 있는 장치가 없다면 이론에 위반되는 사실이 발생해도 얼마든지 이론을 변형하여 이론을 포기하지 않을 수 있다. 앞의 예에서는 조회했을 때 삭제된 데이터가 나오게 하려면 데이터베이스에 저장할 필요 없이 화면에서 보이지 않게 사용자가 입력한 데이터를 임시로 보관한 후에 취소를 누르면 다시 나오게 하면 된다. 이렇게 억지로 끼워맞춘 이론은 현상을 전혀 설명하지 못하는 쓸모없는 것이 된다. 여기에서 스파게티 코드가 생기는 이유도 설명할 수 있다. 잘못된 이론을 세웠는데 테스트를 통과하기 위해 테스트를 피하는 코드를 추가하는 것이다. 테스트를 통과하지 못하는 코드는 버려야 한다.
5. TDD의 본질
이제 TDD가 무엇을 말하는지가 명백해 졌다. TDD에서는 프로그램은 업무에 대한 이론 내지 가설이라고 본다. 테스트는 이 이론을 걸러내는 장치이다. 테스트는 이론을 구상하기 전에 먼저 확정되어야 한다. 개발자는 프로그램을 작성하는 것이 아니라 테스트를 통과할 수 있는 이론을 만들어낸다. 테스트를 통과하지 못하면 프로그램은 버려야 한다.
따라서 TDD는 테스트에 대한 기법이 아니라 개발 방식에 대한 이론이다. TDD는 프로그램을 가설이라고 본다. 가설이 무엇인가? 가설은 가설일 뿐이다. 우리는 가설의 진위 여부를 확정할 수 없다. 가설의 특성을 파악하기 위해 다음과 같은 유명한 예를 보자.
‘모든 백조는 희다.’
이 문장은 참인가 거짓인가? 우리는 아무리 많은 백조를 관찰해도 이 우주가 시작된 후로 처음 나타난 백조부터 이 우주가 끝날 때의 마지막 백조까지 관찰할 수 없기 때문에 위의 문장이 참인지 알 수 없다. 그러나 위의 진술을 부정하는 것은 쉽다. 검은 백조를 관찰하기만 하면 된다. 실제로 오스트레일리아에서 검은 백조를 발견했고 위의 문장은 부정되었다. 따라서 어떤 가설이 참인지는 알수 없지만 거짓인지는 판단하기 쉽다. 이것이 TDD에서 테스트가 하는 역할이다. 테스트를 통과했다고 해서 이 프로그램이 업무를 반영하고 있다고는 볼 수 없다. 그러나 테스트를 통과하지 못하면 이 프로그램은 올바른 이론이 아니기 때문에 버려야 한다. 이런 이론의 채택과 포기 사이의 불균형을 반증 가능성이라고 하는데 20세기의 유명한 과학철학에 대한 이론이다. TDD는 반증 가능성 이론을 따르고 있다.
테스트를 통과하지 못한 이론은 포기해야 하지만 테스트를 통과한 이론의 상태는 모호해진다. 이 이론이 맞다는 보장은 없다. 이것이 테스트를 통과하고 운영으로 넘어간 프로그램의 상태를 설명한다. 테스트를 통과했음에도 불구하고 이 프로그램이 업무를 반영하여 동작한다는 보장은 없다. 사실이 그러한데 끊임없이 유지보수가 발생하는 것을 보면 알 수 있다. 이제 우리는 프로그램의 유지보수가 불필요한 일이 아니라 프로그램의 특성 때문에 발생하는 본질적인 문제임을 알 수 있다. 테스트를 통과한 프로그램은 어떻게 될까? 우리는 프로그램을 보고 다시 현상을 관찰한다. 그리고 다시 새로운 사실을 추가한다. 프로그램은 다시 테스트된다. 테스트를 통과하지 못한 이론은 다시 포기해야 하고 프로그램은 지금까지의 테스트 케이스를 반영하기 위해 처음부터 다시 작성되어야 한다. 이 과정은 다음과 같다.
현상 관찰->사실 확정->이론 구성->테스트->현상관찰
이 과정은 영원히 반복될 것이며 이론은 계속 포기하고 다시 작성될 것이다.
이론은 계속 포기하고 재구축된다. 따라서 프로그램도 이렇게 포기하고 재구축하는 과정을 반복해야 한다.
6. 전통적인 개발 방식 중 버려야 할 것
TDD가 이렇게 반복적인 과정을 거치기 때문에 생산성이 떨어질 것이라는 비판이 있다. 그렇지 않다. 우리가 구상한 이론이 현상을 반영하는지 확인함으로서 우리의 머리속에는 현상에 대한 지식이 계속 축적된다. 재정립한 이론에는 우리가 관찰한 더 많은 사실들이 축적되어 있다. 즉 현실에 더 가까워지는 것이다. 따라서 프로그램은 본질적으로 반복적이고 진화적인 특성을 가질 수 밖에 없다. 그리고 프로그램이 정교하게 다듬어진다는 것은 우리의 머리속에 업무에 대한 지식이 증가한다는 것을 의미한다.
따라서 우리는 전통적인 프로그램 개발 방식 중 몇 가지는 포기해야 한다.
q 업무 분석이 끝난 후 개발하는 것
우리가 고찰한 것에 의하면 분석과 개발은 분리되지 않으며 함께 발전한다.
q 업무 분석가와 개발자를 분리하는 것
바람직하지 않다. 분석가와 개발자가 한 팀이라면 괜찮지만 가장 좋은 방법은 개발자가 업무 분석을 하는 것이다.
q 폭포수 모델
폭포수 모델은 소프트웨어의 특성을 전혀 반영하지 않은 잘못된 모델이다.
7. 작성한 프로그램 지우기
여기에서 이론의 포기가 무엇을 의미하는지 생각해 본다. 이론의 포기는 말 그대로 그 동안 작성했던 프로그램을 지우는 것이다. 이것은 refactoring과는 다르다. refactoring은 기존의 사고방식을 포기하지 않고 변형시키는 것으로 매우 위험할 수 있다. 프로젝트의 초기 단계에서는 refactoring보다는 재 작성이 바람직하다. 프로그램을 포기하지 않으면 기존의 이론을 붙들고 테스트를 통과할 수 있도록 기교를 부릴 것이다. 이것은 우리가 원하는 것이 아니다.
우리가 고찰한 사실은 유지보수에 대해서도 많은 새로운 점을 시사한다. 유지보수란 개발 당시의 이론이 이제는 더 이상 유효하지 않다는 것이다. 따라서 새로운 사실을 추가하고 재 작성해야 한다. 기존의 틀을 유지하려 하면 우리는 기존의 사고방식을 포기하지 않겠다는 것이고 프로그램은 스파게티가 되어 버린다.
8. TDD를 실천한 결과
TDD가 결코 쉽지 않지만 소프트웨어 자체의 내재적인 특성 때문에 이 방식이 올바르다는 것을 명확하다. TDD를 수행해 본 결과 다음과 같은 사실을 알 수 있었다.
첫째, TDD를 수행하면 개발자가 업무 지식 면이나 개발 스타일 면에서 성장한다. 이것은 매우 중요한 사실이다. 개발자는 도메인 전문가및 설계 전문가로 성장한다. 어떻게 설계 전문가가 될 수 있을까? 프로그램의 재구축 과정에서 개발자는 프로그램 로직보다는 프로그램의 구성을 고민하게 된다. 재구축 과정을 빨리 수행하기 위해서 프로그램은 어떤 구성을 가져야 하는가? 재구축 과정이 반복될 때를 대비하여 어떤 라이브러리를 준비해야 하는가? 개발자의 관심은 자연히 코딩에서 패턴, 재사용, 아키텍처로 옮겨지게 된다.
둘째, 처음에는 재구축 과정이 느리지만 시간이 지날수록 점점 빨라진다.
개발자는 재구축 시간을 줄이기 위해 다양한 설계 기법을 사용할 수 밖에 없으며 재구축이 가속도가 붙는다. 그러나 PM이 재촉하거나 고객의 압력으로 재구축을 포기하고 프로그램을 변형시키는 순간 TDD는 멈추고 개발자는 예전 방식으로 일을 진행하게 된다. 따라서 장기적으로 TDD는 이점이 많다. 개발자가 설계전문가 및 도메인 전문가로 성장한다면 유사한 프로젝트를 다음에 수행할 때는 더 안정적이고 빠르게 시스템을 구축할 수 있다. 그러나 프로젝트 PM이 개발자를 조급하게 재촉하면 TDD는 진행되지 않는다.
세번째 별도의 테스트 기간과 버그 수정 기간이 사라진다. 프로그램을 재구축하는 과정에서 오류 수정이 자연스럽게 이루어진다. TDD가 자연스럽게 품질을 보장하는 것이 TDD의 좋은 점이다.
위의 그림을 보면 오류가 생기는 즉시 코드가 수정되기 때문에 프로그램의 품질이 향상된다는 것을 알 수 있다.
9. TDD를 실천하기 위해 해야할 일들
TDD를 실천하기 위해서는 다음과 같은 것을 실천해야 한다.
첫째, TDD는 프로그램을 포기하고 재구축할 것을 요구한다. 만일 전통적인 방식으로 분석, 설계 과정을 모두 거친 후에 개발에 들어간다면 개발시간이 짧기 때문에 TDD의 방식을 따르는 것은 불가능하다. 따라서 TDD를 따르려면 프로젝트 시작부터 개발에 들어가야 한다. 즉 고객의 요구사항을 듣고 테스트 케이스를 만든 후 바로 개발을 시작해야 한다. 그러므로 고객과의 인터뷰, 요구사항 작성, 분석 클래스 작성, 유스케이스 작성 등은 포기해야 한다. 바로 개발에 들어가야 겨우 일정을 맞출 수 있다. TDD로 하면 개발이 빠르지 않다. 따라서 TDD에 적합한 방식은 Agile일 수밖에 없으며 다른 기존의 개발 방법론에 TDD를 적용하는 것은 불가능하다.
두번째, 개발자의 역할을 바꾸어야 한다. 개발자가 능동적으로 업무 분석에 참여하지 않으면 TDD는 진행되지 않는다. 즉 개발자는 더 이상 프로그램 작성자가 아니라 업무 분석 결과를 프로그램으로 옮기는 사람이다. 아니면 업무 분석가가 개발을 해야 한다.
세번째는 심리적으로 자신이 만든 결과물을 포기하는 것이 쉽지 않다는 것이다. 자신이 했던 일을 포기하고 처음부터 다시 하는 것을 고통스럽다. 만일 이런 포기 과정이 프로젝트 초기에 일어난다면 괜찮지만 프로젝트가 상당히 진행된 후 자신이 잘못된 이론을 세우고 있음을 알았을 때는 어떻게 할까? 프로그램을 재구축할 시간을 허락할 PM이 있을까? 아마 기존 프로그램을 변형하여 문제를 해결하도록 지시할 것이다. 그러나 이런 프로그램은 현실을 반영하지 못하며 결국 쓸모 없어진다.
네번째는 개발자는 테스트 케이스를 작성할 수 있도록 훈련시켜야 하고 업무 분석가는 모호한 모델링이 아닌 테스트 케이스를 분석의 결과로 도출하도록 훈련시켜야 한다. 훈련은 기존의 관습을 깨고 새로운 사고방식을 주입하는 것으로 매우 어려운 과정이다.
다섯째, 처음부터 개발한다. 분석, 설계, 개발 과정을 포기하고 짧은 (최대 2주) iteration을 두어 개발을 처음부터 시작해야 한다.
여섯째, 개발자에게 업무를 고민할 충분한 시간을 확보해 주어야 한다. 이를 위해 불필요한 문서 작업, 사무적인 작업, 회의는 모두 줄여야 한다.
일곱째, PM의 관리스타일의 변화를 요구한다. PM은 고객이 개발자에게 직접 일을 주지 못하도록 버퍼를 만들어야 한다. PM과 PL이 주로 해야 할 일은 개발자를 보호하는 것이다.
여덟째, TDD를 유도할 수 있는 개발 환경을 구축해야 한다. refactoring, 자동 빌드, 자동 테스트를 지원하는 툴을 제공해야 한다.
2004년 2월, 어떤 컨설턴트가 품질 문제로 씨름하고 있는 한 회사에 TDD를 소개했다. 출시 후 6개월 동안 주석을 제외한 순수 실행코드 기준으로 1,000라인 당 평균 10개의 결함이 보고되고 있었다. 열악한 품질은 그 회사의 명성과 고객만족에 타격을 주었다.
이 문제를 해결하기 위해 그 팀은 스크럼이라는 애자일 개발 프로세스를 사용하였고 곧 TDD를 채택하였다. TDD를 채택한 이후 보고된 결함 수는 1,000라인 당 3개 이하로 줄어들었으며 대략 80%~90%의 개선을 이루었냈다.
품질이 향상되자 효과는 여러 형태로 나타났다. 결함(개발 중에 발생한 것과 사용자가 보고한 것까지 모두 포함)을 잡아내는데 훨씬 더 적은 시간을 사용했기 때문에 생산성이 급등했다. TDD 적용 전에 한 사람이 한 달 동안 기능 점수로 7점을 개발했는데, TDD 적용 후에는 23점이나 개발하게 되었다. 그 팀은 결함을 훨씬 적게 내면서도 3배 이상의 생산성 향상을 이루어 냈다.
11. 결론
TDD는 개발 방식의 문제이며 개발자에게는 개발 스타일의 변화를 요구하며 분석가는 개발 능력을 요구한다. 또한 프로젝트 관리자는 개발자의 도메인 지식이 성장하고 설계 능력이 향상되도록 유도해야 한다. 즉 모든 면에서의 변화를 요구한다. 뿐 만 아니라 고객도 개발 스타일의 변화에 따라 어떻게 프로젝트에 참여해야 하는지 교육을 받아야 한다. 훈련과정을 만들어서 고객, 개발자, PM, 심지어 개발 프로젝트를 총괄하는 경영진까지 훈련을 받아야 한다.
또한 TDD를 적용하기 위해서는 좋은 개발툴이 있어야 한다. 이 개발툴은 프로그램의 전체 구조를 쉽게 파악할 수 있도록 도와줘야 한다. 재구축을 빨리 진행할 수 있는 개발툴이 있어야 한다. 어느정도 스킬이 쌓이면 refactoring을 할 수 있어야 한다. 또한 테스트 케이스는 빌드 시점에서 자동으로 테스트를 수행할 수 있어야 한다. 오픈 소스 툴을 이용할 수 있으나 프로젝트에서 셋팅하여 사용하려면 전문 인력이 투입되어야 한다. Microsoft Team Foundation Server는 전문 인력의 투입을 최소하면서 프로젝트에서 유연하게 적용할 수 있는 툴이다. 그러나 TDD를 적용하기 위해서는 개발 인력에 대한 충분한 훈련 기간(최소 1년 이상)이 필요하다.
