목차
개요
일반적인 개발 방식에서는 요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포의 개발 주기를 갖는다. 이 방식의 단점은 다음과 같다.
- 소비자의 요구사항은 명확하지 않거나 변경될 수 있다.
- 이에 따라, 설계 또한 변경된다. 이를 배제해도 애초에 완벽한 설계란 어렵다.
- 이에 따라, 구현 또한 변경된다. 수정 과정에서 소스코드 품질이 저하될 수 있다.
- 단위 유닛의 테스트를 위해 연관한 모든 부분을 테스트해야 한다. 테스트 비용 증가 외에도 전반적인 버그 검출이 어려워진다.
이를 보완하기 위한 방법중 하나로, TDD가 있다.
테스트 주도 개발 (TDD, Test Driven Development)
테스트 작성 이후, 이를 통과하는 소스 코드를 작성하는 프로세스를 짧은 주기로 반복하는 개발 방법론
코드 작성 이후 테스트하는 일반적인 개발 방식에 대조된다.
eXtreme Programming의 'Test-First' 원칙에 기반한다.
익스트림 프로그래밍 (XP, eXtreme Programming)
대표적인 애자일 방법론 중 하나이다.
반복적으로 소규모 프로토 타입을 고객에게 전달함으로써, 요구사항 변화에 대응 및 빠른 피드백을 목표로 한다.
요구사항이 불확실하고 변경이 잦을 때 유용한 개발 방법론이며, 개발문서 보다 소스코드에 우선 순위를 둔다.
TDD 개발 절차
Red, Green, Blue 단계로 나뉜다.
Red - 실패하는 테스트를 작성한다.
* 검증 코드가 아닌 운영(동작) 코드로 인한 실패여야 한다.
Green - 테스트를 성공하기 위한 최소 코드를 작성한다.
Blue - 리팩토링을 수행한다.
Red 단계가 잘 이해가 되지 않으므로, 예를 들어보자.
public class CalculatorTest {
@Test
public void testAddition() {
Calculator calculator = new Calculator();
int result = calculator.add(1, 2);
assertEquals(3, result);
}
}public class Calculator {
public int add(int a, int b) {
return a * b;
}
}
Red 단계 -> add 메서드를 구현했지만, 의도한 덧셈과 달리 곱셈을한다. 이는 이후 assert 검증에서 실패할 것이다.
Green 단계 -> add 동작을 수행하는 최소 코드로 수정한다.
Blue 단계 -> 코드 일반화와 중복코드 제거 등 리팩토링을 수행한다.
TDD의 장점
1. 디버깅 효율성
애초에 테스트 코드를 기반으로 코드를 작성하는 방법론이다. 작성해놓은 테스트 코드로 부분검증 할 수 있다.
이는 A의 검증을 위해 연관된 B,C,D..의 정상 여부를 파악해야 하는 개발 이후 테스팅과 대조된다. 테스팅 비용이 절감되며, 전반적인 버그를 찾아내기 쉽다.
2. 신뢰성 향상
배포 전 최종 검토 단계에서, 피어 리뷰나 인스펙션 등을 수행하며 동작 검증 및 버그를 탐색한다. 혹은 지인이나 관계자에게 배포하여 수행 할 수도 있다. 이는 사용하기 충분한 소프트웨어 인지 확인하는 과정이다. 이에 반해, TDD는 개발 단계부터 어느 정도의 검증을 받는다. 단위 테스트로 동작을 검증하며 진행하기 때문이다. 이는 코드 뿐만 아니라, 개발자의 불안함 또한 해소한다.
3. 유연성 향상
일반적인 개발은 서비스의 전체적인 틀에 맞춰 세부 기능을 구현한다. 이에 반해, TDD는 단위 기능의 동작 및 예외사항을 고려하며 개발할 수 있다. 재설계와 기능 수정 및 추가의 경우에도 효율적으로 대처할 수 있다.
TDD의 단점
1. 생산성 저하 가능성
TDD의 창시자(혹은 재발견자) 켄트 백은, 이를 불안함을 지루함으로 바꾸는 마법의 돌이라고 칭했다.
항상 별도의 테스트 코드를 작성해야 한다. 테스트 코드를 검증해야한다. 사람에 따라 지루하고 귀찮은 작업일 수 있다. 납기일을 준수해야 하는 SI 프로젝트나, 퍼포먼스 중심인 프로젝트엔 적합하지 않을 수도 있다.
2. 준수의 어려움
일반적인 개발 방식이 몸에 익은 사람일 수록, 순서를 뒤집는 것이기에 적용하기 쉽지않다. 소스 코드에는 적용 가능하나 테스트 코드에는 어긋나는 상황에서, 소스 코드를 위한 테스트 코드 이지만 원칙을 준수할지 모호하다. 하지 않는다면, 일관성을 해치게 된다. 또한, 켄트 백은 테스트 코드와 소스 코드의 균형을 강조했다. 목적이 테스트 코드 작성 자체가 되면 안된다.