+ / 테스트 주도 개발

초기의 개발 프로세스

전통적 공학론적 개발 프로세스

>> 사전에 철저히 검증된 계획 하에 장기간에 걸쳐 많은 인원과 비용을 투입해 목표를 완수

 

소프트웨어 개발도 초기에는 위 프로세스를 따라 폭포수 모델 등을 따름

>> 구현하게 될 소프트웨어의 규모가 커지고 복잡해져 소프트웨어 위기(Software Crisis) 문제

 

초기 개발 프로세스의 문제

소프트웨어는 유동적이고 예측하기 어려움

>> 확장가능성, 개방적 구조 요구

 

1. 개발에 적용할 수 있을 수준의 구체적인 요구사항을 작성하는 것이 매우 어려움

2. 규모가 커질수록 설계에 요구되는 시간과 비용이 기하급수적으로 증대

3. 실제 개발에 들어가고나서 정해진 요구사항이 변경되거나 다양한 문제점 발견

4. 위와 같은 문제로 인해 작업 난이도 및 개발일정을 예측하는 것이 어려움

 

테스트 주도 개발(Test Driven Development)

익스트림 프로그래밍 개발방법론의 실천 방안 중 하나

>> 개발이 이루어진 다음 그것이 계획대로 잘 완성되었는지 테스트 케이스를 작성하고 테스트하는 방식이 아닌

>> 테스트 케이스를 먼저 작성한 다음 테스트 케이스에 맞추어 실제 개발 단계로 이행하는 개발방법론

 

잠재된 상황을 가정하지 않고 테스트 케이스만을 완벽히 수행하는 것을 목표

>> 매우 빠르게 목표를 완료

 

TDD 자체가 하나의 테스트가 완전하지 않다는 것을 가정

>> 1차 테스트를 완료한 다음 새로운 테스트 케이스를 확장해 작성하고 

>> 그것을 통과하기 위한 개발에 들어가는 과정을 끊임없이 반복해 큰 규모의 프로젝트 완성

 

장점

코드의 유지보수가 용이해짐

>> 다른 코드의 행위가 보증되므로 원하는 부분에만 신경을 쓸 수 있음

>> 테스트가 있으면 안심하고 코드를 리팩토링할 수 있음

 

프로그래밍 시간 단축

>> 테스팅은 디버깅을 해야 할 범위를 단위 안으로 제한함으로써 디버깅 시간을 크게 줄임

 

뛰어난 프로그램 소스코드 기록

>> 유닛 테스트는 코드가 어떻게 행동해야 하는지를 기록

 

단점

실수를 미리 인지할 수 있는가

>> 사람의 실수는 코드를 작성할 때 인지할 수 없음

>> 코드를 쓰고 문제가 발생했을 때 테스트를 작성하나 테스트를 작성하고 코드를 작성해 문제가 발생하나 똑같음

 

테스트가 모두 통과해서 버그가 없다고 생각하는 함정

>> 테스트의 존재가 구현코드에 버그가 없고 구현 코드가 비즈니스 요구사항을 완벽히 만족시킨다는 것을 증명하진 않음