Test Driven Development (TDD)은 개발이 이루어진 다음 그것이 계획대로 잘 완성되었는지 테스트 케이스를 작성하고 테스트하는 타 방식과는 달리,
테스트 케이스를 먼저 작성한 다음 테스트 케이스에 맞추어 실제 개발 단계로 이행하는 개발방법론을 말한다.
테스트 케이스를 먼저 작성하고 이후 그 테스트 케이스를 통과하는 구현체에 내용을 작성한다, 즉 테스트가 개발을 주도한다.
이러한 일련의 작업을 반복하며 정상 동작에 대한 피드백을 적극적으로 받으며 받은 피드백을 통해 코드를 리팩토링한다.
이로써 우리는 동작하는 깨끗한 코드 를 얻게 된다. 좀 더 눈에 들어오게 절차를 정리하자면 아래와 같다.
이 과정을 흔히 Red-Green-Refactor
라고 부른다.
일반적인 개발의 흐름을 보자면 우리는 구현체를 구현한 이후 선택적으로 테스트 코드를 작성한다.
쉽게 순서를 바꾸면 된다. 그러면 test coverage 가 기본 80%
가 넘는 경이로움을 느끼게 된다.
실패하는 테스트 케이스를 먼저 만든다. 실패하는 테스트 케이스를 만들 때는 프로젝트 전체 기능에 대하여 모든 테스트 케이스를 작성하는 것이 아니다. 가장 먼저 구현할 기능의 테스트 케이스를 작성한다.
실패한 테스트 케이스를 통과시키기 위하여 코드를 작성하여 테스트를 통과시킨다.
구현한 코드에 중복이 있거나, 개선할 수 있다면 리팩토링을 진행한다. 리팩토링을 진행하고 나서도 테스트 케이스가 성공하는지 확인한 후 다시 실패(Red)로 돌아가서 다른 기능 구현을 위한 테스트 케이스를 작성한다.
TDD는 개발하는 과정에서 테스트를 내포하고 있기 때문에 코드 작성 단계에서 버그를 줄여나갈 수 있다. 또한 TDD에 사용할 단위테스트를 실행하기 위해 기능을 아주 작은 단위의 함수로 쪼개게 되는데, 이로 인해 종속성과 의존성이 낮은 모듈로 조합된 코드를 만들게 된다.
TDD는 분명 좋은 품질의 코드를 만들 수 있는 방법론이지만 코드의 생산성이 크게 저하된다. 비즈니스 로직, 각종 코드 디자인에도 많은 시간이 소요되는데 테스트 코드까지 작성하기란 벅찬일 일수있다. 코드 품질보다는 빠른 생산성이 요구되는 상황에서 TDD는 걸림돌이 될 수 있다.
또한 진입 장벽이 존재한다. 어떤 부분을 테스트해야 할지, 어떻게 테스트해야 할지, 어떤 프레임워크를 써야 할지 등 여러 부분에 대한 학습이 필요하고 적응하는 데 시간이 소요된다.
테스트 주도 개발. TDD 방법론에서는 Unit test 같은 테스트 코드를 먼저 작성 후, 테스트를 통과하는 코드를 짠다. 작은 단위로 코드를 작성하는 것으로 시작해 기능이 추가될 때마다 테스트 먼저 시행 후 코드를 작성한다.
테스트 코드를 먼저 작성한 후에 개발을 진행하므로 Test-Driven Development라고 부른다.
소프트웨어를 빠르게 개발할 때 쓰는 방법으로, 변경이나 수정이 잦은(=불확실성이 높은) 애자일 환경에 적합한 방법론이다.
생년월일(input)을 입력하면 현재 나이(output)를 출력하는 프로그램을 만든다고 가정하자.
처음에는 간단히 2015, 2018를 입력하면 3이 출력되게끔 목표를 잡는다.
2015, 2018를 입력하면 3이 나오는 테스트 코드를 작성한다.
테스트를 통과할 코드(1번을 목표로 작성한 코드)를 작성한다.
예) 올해 연도 - 태어난 해 (2018 - 2015)
테스트 프로그램으로 이 프로그램(3번 코드)을 실행한다.
통과했으면 새로운 테스트를 추가한다.
이번에는 살을 붙여서 생월을 추가했을 때 나이를 계산하는 프로그램을 만든다.
위와 같이 살을 붙이는 작업을 반복해서 수행한다.
웹개발에서 Unit test 수행 시 실제 데이터가 출력되는 형태로 테스트 코드를 작성해야 하므로 프론트에 JSON 형태 목데이터를 미리 전달할 수 있다. 프론트에서도 백에서도 개발 도중 자료구조를 수정하거나 key 이름을 수정할 필요가 없으므로 커뮤니케이션 비용을 아낄 수 있다. 또한 코드 리팩토링을 할 때 코드를 고치면서 생길 수 있는 오작동을 미리 잡아낼 수 있다.