테스트 주도 개발

풀 메탈 패닉의 TDD-1에 대해서는 투아하 데 다난(풀 메탈 패닉!) 문서를 참조하십시오.
  • 이 문서는 TDD(Test Driven Development)로도 들어올 수 있습니다.

1 개요

전통적인 공학론적 개발 프로세스는 사전에 철저히 검증된 계획 하에 장기간에 걸쳐 많은 인원과 비용을 투입하여 목표를 완수하는 방식을 따른다. 소프트웨어 개발 역시 초기에는 이러한 프로세스에 따라 폭포수 모델 등을 따랐으나, 구현하게 될 소프트웨어의 규모가 커지고 복잡해짐에 따라 소프트웨어 위기(Software crisis)라는 문제에 봉착하게 되고, 소프트웨어 공학에서는 소프트웨어 개발 과정이 다른 공학적 방식과 큰 차이가 있음을 인지하게 된다.

소프트웨어는 유동적이고 예측하기 어렵다. 또한 소프트웨어가 발전하면서 점차 확장가능성, 개방적 구조를 요구하게 되었다. 따라서 구체적으로 개발이 언제 완료될 것인지 예측하는 것이 매우 어려울 뿐더러, 인원과 비용을 늘린다고 해서 개발 시간의 절감이나 질적인 성과를 보장할 수 없다. 소프트웨어의 규모가 커지고 복잡해질수록 기존의 폭포수 모델을 적용했을 때 다음과 같이 다양한 문제점이 발견되었다.

1. 개발에 적용할 수 있을 수준의 구체적인 요구사항을 작성하는 것이 매우 어려움. 불가능함.
2. 규모가 커질수록 설계에 요구되는 시간과 비용이 기하급수적으로 증대됨.
3. 실제로 개발에 들어가고나서 정해진 요구사항이 변경되거나, 다양한 문제점이 발견됨.
4. 위와 같은 문제로 인해 작업 난이도 및 개발일정을 예측하는 것이 어려움.

기존의 계획주도 개발방식에서는 세운 계획대로 개발이 흘러가지 않으며, 그것을 보완하기 위해 언제나 개발이 지연되었고, 개발자에게 주어지는 스트레스와 과중한 업무, 그 결과 떨어지는 생산성과 상품성 등에 직면하여 소프트웨어 공학자들은 전통적인 개발 프로세스에 큰 의문을 제기하였다. 이에 완전한 설계를 지향하는 폭포수 모델을 폐기하고, 초기의 설계 비용을 줄이고자 작은 규모의 소프트웨어를 완성한 다음 그것을 점차 보완해가며 복잡한 소프트웨어를 완성하는 나선형 모델(Spiral model)을 도입하는 등 산업에서는 보다 경험적 프로세스 제어 모델로 이행하게 된다.

애자일 프로그래밍(Agile programming) 방식은 계획과 문서에 의존하는 기존의 방식을 부정한다. 미래에 대한 예측을 차단하고 지속적인 프로토타입의 완성을 반복하여 그때그때 소단위 요구사항을 추가하고 기존의 문제점을 해결하여 점차 큰 규모의 소프트웨어를 완성하는 개발 방식이다. 익스트림 프로그래밍(eXtream Programming, XP)은 대표적인 애자일 프로그래밍 개발방법론 중 하나로, 고객이 원하는 소프트웨어를 빠른 시간 내에(약 2주) 프로토타입의 형태로 전달하고 이를 통해 고객이 원하는 소프트웨어를 이끌어내며, 수시로 발생하는 요구사항에 대처하는 것을 목표로 한다.

다른 애자일 방법론과 구별되는 XP의 특징은 테스팅이다. 구현과 테스트를 하나의 쌍으로 취급하여, 실제 구현과 동시에 테스트 코드를 작성하도록 하며, 이것에 기반한 프로젝트 발전 과정은 애자일 방법론의 기본 개념인 "반복적으로 프로토 타입을 고객에 전달함으로써 고객의 요구사항 변화에 민첩하게 대응한다"를 실천하는데에 큰 도움을 줄 수 있다. 왜냐하면 매번 프로토 타입을 고객에 전달함에 있어서 프로토 타입 자체로써 버그가 상대적으로 적은 완벽에 가까운 데모를 경험하게 해줄 수 있기 때문이다.

테스트 주도 개발(Test Driven Development, TDD)은 익스트림 프로그래밍 개발방법론의 실천 방안 중 하나이다. 개발이 이루어진 다음 그것이 계획대로 잘 완성되었는지 테스트 케이스를 작성하고 테스트하는 타 방식과는 달리, 테스트 케이스를 먼저 작성한 다음 테스트 케이스에 맞추어 실제 개발 단계로 이행하는 개발방법론을 말한다. 묵시적으로 잠재된 상황을 가정하지 않고 테스트 케이스만을 완벽하게 수행하는 것을 목표로 하기 때문에 매우 빠르게 목표를 완료할 수 있다. 한편, TDD 자체가 하나의 테스트가 완전하지 않다는 것을 가정하고 있기 때문에 1차 테스트를 완료한 다음에 새로운 테스트 케이스를 확장해서 작성하고 그것을 통과하기 위한 개발에 들어가는 과정을 끊임없이 반복하여 큰 규모의 프로젝트를 완성해가는 것이다.

2 분류

테스트 주도 개발에서 작성되는 테스트는 단위 테스트가 대표적이다. 먼저 단위 테스트는 말 그대로 한 단위[1]만을 테스트하는 것이다. 단위 테스트를 작성하려면, 일단 테스트를 작성한 뒤 컴파일 에러가 일어나지 않도록 테스트에서 쓰이는 클래스와 그 메소드의 스텁을 만들어 둔다. 테스트가 실패하는 것을 확인하고(= 컴파일 에러는 없는 것을 확인하고) 클래스를 구현한다. 클래스에서 필요한 다른 클래스가 필요하면 일단 스텁으로 지금 작성중인 클래스의 테스트를 통과하게만 해 두고, 나중에 그 클래스의 테스트 케이스를 작성한 후 구현한다. 이런 식으로 프로젝트 전체를 완성해 나간다. 하지만 단위 테스트는 단위 하나하나에 대해서만 검증할 수 있으므로, 이를 해결하기 위해 인수 테스트를 작성한다. 사실 인수 테스트는 전통적으로 사람(QA)의 영역이었지만, 코드로도 약간 구현해두면 품질에 큰 도움이 된다[2].

3 장점

  • 코드의 유지보수가 용이해진다
프로그래밍 개발에서는 처음 개발할 때보다 이미 개발한 코드의 버그를 수정하고, 최적화하고, 새 기능을 추가할 때 비용이 더 들어간다. 그런데 테스트를 작성하면 코드에 절대로 뒤떨어지지 않는 문서가 탄생하며, 다른 코드의 행위가 보증되므로 원하는 부분에만 신경을 쓸 수 있으며, 테스트하기 쉬운 코드는 자연히 품질이 높아지므로 다시 읽기도 편하다. 또한 테스트가 있으면 안심하고 코드를 리팩토링할 수 있다.
  • 프로그래밍 시간이 단축된다.
테스트를 작성하는 시간을 포함시키고도 오히려 전체 작업 시간은 줄어든다. 왜냐하면 프로그래밍에서 대부분의 시간이 디버깅에 투입되는데, 테스팅은 디버깅을 해야 할 범위를 단위 안으로 제한함으로써 디버깅에 들어가는 노고를 크게 줄여준다. 또한 유지보수시에도 상술한 이유로 효율이 높아진다.

4 TDD 프레임워크

  • xUnit
뒤에 -Unit이란 접두사가 붙는 여러 단위(unit) 테스트 프레임워크의 통칭이다. 자바의 사실상 표준 테스트 프레임워크인 JUnit이 가장 유명하다. 최초의 xUnit 프레임워크는 SUnit인데, 켄트 벡이 Smalltalk용으로 개발했다. 이후 켄트 벡과 에릭 감마가 함께 이를 Java용인 JUnit으 포팅했다. 비행기를 같이 타고 가다가 JUnit을 만들었다고 한다. 이 외에도 C++용의 CppUnit, .NET용의 NUnit등이 있다.
Java 코드에 대하여 Code coverage를 구할 수 있는 툴이다. Code Coverage를 지원하는 Open Source 툴중에 가장 활성화된 커뮤니티를 가진다. [3] 이클립스, Jenkins,Sonar,NetBeans에 플러그인형태로 사용할 수 있으며 ant,Maven 등의 빌드툴을 사용한다.
  1. ↑ 일반적으로 클래스
  2. ↑ 현재 코드가 완전히 사람을 대체하는 것은 불가능한데, 실제 응용 프로그램에서는 가능한 경우의 수가 무한히 많기 때문이다.
  3. ↑ 그래도 영어 커뮤니티가 전부이다...