TDD란?
Test Driven Development의 줄임말이다.
Agile 방법론을 실천하기 위한 여러 개발론 중 하나다.
테스트가 개발의 축이 된다.
어떻게?
Agile 방법론 자체가 동적이고 능동적으로 기획과 개발의 선을 넘나들며 개발을 진행하는 방식이다.
정형화된 [기획->개발->테스트->수정]의 과정을 가진 Water Fall 방법론이나 Bohem's spiral 방법론과는 다른
Agile만의 장점이자 단점으로 꼽히는 점이다.
그 중에서도 TDD는 매우 짧은 개발 사이클을 가지는 개발론이다.
보편적으로 소프트웨어 개발을 진행할 때, 기획을 받아 기능을 구현한 후 해당 기능을 대상으로 테스트를 진행한다.
TDD는 이것을 역순으로 진행한다고 생각하면 쉽다.
과정 1
1. 먼저 테스트 케이스(입력 인자와 반환 결과)를 구성한다.
2. 그 후 테스트 케이스를 성공시키기 위한 소스 코드를 개발한다.
3. 마지막으로 작성한 코드를 표준에 맞게 다듬는다.(리팩토링)
하지만 이것을 구현 후 테스트 하던 작업 순서에서 바로 적용하면 바로 어려움에 부딪힐 것이다.
서비스 기획 요구 사항을 구현하기 위해 개발자는 여러 기능을 만들어 하나의 함수로 묶어놓게 되고 그 함수들을 또 하나로 묶게 되고 이것을 반복할 것이다. 그리고 이것을 통째로 테스트를 돌리게 된다.
물론 그 결과는 참담할 것이다. 에러는 발생할 것이고, 발생 지점을 찾기 위해 그 긴 코드를 여러 번 정독해야 한다.
과정 2
이것을 예방하기 위해서 필요한 것은 무슨 훌륭한 기술이 아닌 개발 방향과 태도다.
그리고 그 방법은 과정 1의 절차 크게 차이 나지 않는다.
1. 먼저 테스트 케이스(입력 인자와 반환 결과)를 구성한다.
2. 그 후 테스트 케이스를 성공시키기 위한 돌아가기만 하는 최대한 짧고 간단한 소스 코드를 개발한다.
3. 마지막으로 작성한 코드를 표준에 맞게 다듬는다.(예외처리 + 리팩토링)
개발자가 최대한 짧고 간단하게 개발해 소스 코드 파악과 테스트 진행을 수월하게 하는 것이 전제이다.
짧고 간단한 코드를 구현하여 기능의 분할 및 객체화를 우선시 한다.
또한 이렇게 되기 위해서는 기능 기획의 규모를 작게 해야한다.
[작고 단순하고 명확한 기능 기획 -> 테스트 케이스 작성 -> 짧고 간단한 구현 -> 검증] 으로 전체 개발 사이클을 매우 짧게 반복하는 것이다.
효과
짧은 코드를 구현하여 각 기능들이 명확해진다.
테스트 케이스가 작성되어 있기 때문에, 기존 소스 코드를 수정한다 하더라도 동일한 테스트와 결과를 얻을 수 있다.
최종적으로 소스 코드의 검증 시간이 줄고 안정적으로 사용할 수 있다는 것이다.
자신이 개발한 기능이 아니지만 수정을 해야하는 경우가 빈번한데, 이럴 때 해당 기능이 이미 테스트 케이스를 가지고 있다면 안정적으로 수정할 수 있을 것이다.
결론
개발 방법론이라는 것이 항상 그렇듯이, 개발만이 아니라 기획에서도 도와줘야 하기 때문에 처음부터 적용되어 진행된 것이 아니라면 사실 100% 활용하기 힘들다.
하지만 TDD의 경우, 기획에서 단순 명확한 기획을 주지 않는다고 하여도 개발에서만이라도 적용할 여지가 충분히 있다. 기획을 분할하여 내부 기능들을 만들고, 그것에 대한 테스트 케이스를 만들어, 각 기능 함수별로 테스트를 진행하면 충분히 그 효과를 얻을 수 있다는 것이다.
Java의 JUnit과 같은 함수를 대상으로 단위 테스트를 진행한다는 것은 큰 도움이 될 수 있다.
단위 테스팅 툴의 적용은 오래 걸리거나 힘들지도 않고, 상용화에 영향을 주지도 않는다. 만약 사용하고 있지 않다면, 남는 시간에 써보는 것이 좋을 거라고 생각한다.
일하다가 답답해서 써본 결과, 썩 나쁘지 않다. 좋으면 좋았지.