TDD(Test-Driven Development)란?

😀지금 나는 작성한 기존의 코드에 대해서 일일히 테스트 코드를 만들고 있다. 항상 테스트 코드에 대해서 검색하고 알아보다보면, TDD라는 용어가 나온다. 정확히 TDD가 무엇이고 어떠한 장점들이 있는지 알아보자.

TDD란?

TDD는 Test-Driven Development의 약자로 테스트를 중심으로 개발을 진행해 나가는 개발 방법론 중 하나이다. 그냥 테스트 코드를 작성하는 것이 아니라 하나의 방법론이기 때문에 일련의 과정을 따라 개발해 나가는 순서가 있다.

일반적은 개발은 우리가 하던 코드를 작성하고 해당 코드에 대해서 테스트 코드를 작성하는 현재 내가 처한 상황이 일반적인 방법인데, TDD는 테스트 코드를 먼저 작성하고, 그에 맞는 코드를 작성하는 순서로 개발을 진행한다. 이 과정에서 테스트가 개발자의 설계 도구로서의 기능을 하면서 코드의 품질을 향상시켜주는 특징이 있다.

TDD의 주요 흐름

위의 TDD설명에 포함된 내용에서 설명했듯이 방법론이고 순서가 필요한다. 이 순서의 흐름은 하나의 사이클을 가진다.
Red-Green-refactor의 사이클을 가지면서 개발을 진행하게 된다.

큰 사이클로 보면 위의 과정이라고 볼 수 있겠지만 해당 사이클을 좀더 세분화 하면 아래와 같은 사이클을 돌면서 개발을 진행하게 된다고 볼 수 있다.

1. 설계 및 테스트 코드작성 : 우선 개발자는 설계를 구상하고 테스트 코드를 작성한다. 가장 중요한 단계이다. 설계 및 구상을 기반으로 테스트 코드를 작성 해야 하는데, 개발자가 만들어야할 기능에 대해서 완벽하게 분석하고 이해하지 못했다면, 제대로된 설계가 이루어지지 않고, 그에 대한 테스트 코드만을 작성하게 되면 분명 문제가 발생할 수 있기 때문이다. 또한 이 단계에서는 그저 테스트 코드만 작성할 뿐 실질적으로 서비스에 영향을 미치는 코드를 작성하는 것이 아니다. 이 단계에서 되도록 작은 단위로 테스트 코드를 작성한다.

2. 테스트 실패 : 테스트 코드를 작성완료 했다면, 테스트를 실행 했을때 Fail이 나올것이다. 왜냐? 당연히 실질적인 코드를 작성하지 않았으니까.

3. 코드 작성 및 테스트 성공 : 실패한 테스트를 통과 시키기 위한 실질적인 코드를 작성한다. 하나의 기능에 검증해야할 테스트 케이스는 여러개일 것이다. 위 1번 과정에서 작은 단위로 테스트 케이스를 작성하였다면. 딱 그 정도 테스크 테이스만 통과될 수 있도록 최소한의 코드를 작성한 후 테스트를 진행하여 PASS를 얻는다.

4. 전체 테스트 성공 : 제대로 작성된 테스트 코드라면 다른 케이스에 대해 문제를 일으키진 않겠지만, 혹시나 잘못 설계된 테스트 코드가 있거나, 휴먼 에러로 인한 실수가 발생했을 때는 다른 케이스에 영향을 끼칠수도 있기 때문에 방금작성한 테스트 케이스가 아닌, 이전에 작성했던 전체적인 테스트를 실행하여 문제가 없는지 확인한다.

5. 리펙토링 과정 : 위의 2~3의 과정에서 작성한 테스트 케이스와 통과의 과정은 해당 기능이 정상 동작하는지 확인하는 역할을 한다. 현재 내가 작성한 코드가 4번 과정까지 거쳐 기능에 문제가 없음을 확인했으니, 내가 작성할 코드를 좀 더 코드 퀄리티를 높이기 위한 리펙토링을 진행한다. 코드를 깔끔하게 다듬었다면 다시 1번 과정으로 돌아가서 해당 기능에 필요한 다음 step의 테스트 케이스를 작성하고 반복하면서 기능을 완성해 나간다.

TDD를 사용할 때의 장점

위의 TDD의 반복적인 주기를 통해 코드의 품질이 높아지는 이유는 몇 가지가 존재한다.

1. 테스트를 먼저 작성함으로써 개발자는 코드가 동작해야 할 기대 결과를 명확하게 정의 해야한다. 어떠한 값을 넣고 어떠한 결과가 나오게 동작할 것인지 이미 구상을 하고 테스트 코드를 작성하게 된다. 이는 코드의 명세(Specification) 역할도 하므로 개발자와 클라이언트 간의 의사소통에 도움을 줄 수 있다.

2. 최소한의 기능을 구현하는 단계에서 개발자는 간결하고 단순한 코드를 작성하게 된다. 적은코드의 작성을 통해 코드의 가독성과 유지보수성을 높여줄 수 있는 코드를 작성하기 쉽다.

3. 리팩토링 단계에서 작성한 코드를 개선하고 중복을 제거하여 코드의 재사용성을 높이고 결함을 예방할 수 있다.

4. 초기에는 개발 속도가 상대적으로 느릴 수 있지만, 테스트를 통해 발생하는 결함을 초기에 찾아내므로 이후에 발생할 수 있는 문제를 사전에 예방할 수 있다. 따라서, 결함을 수정하는 시간과 비용을 대폭 줄일 수 있고, 테스트 케이스를 작성하면서 코드를 좀 더 꼼꼼히 검토하고 디버깅 할 수 있어, 코드의 품질을 높이고 개발 생산성을 높일 수 있다.

TDD를 사용할 때의 단점

TDD는 하나의 개발 방법론이지, 개발을 위한 정답론이 아니다. 따라서 장점이 있다면 분명 단점도 존재한다.

1. 우선 테스트 코드의 작성방식과 처음 TDD를 적용해서 개발을 진행하게 되면 학습곡선이 늘어나고, 작은 단위로 작성하고 틀리고, 성공시키고, 고치고를 반복하며 테스트 케이스를 작성하는 과정은 추가적인 시간과 노력을 요구한다.

2. 처음 접하는 기술이나 신규 기능에 대해서 구현을 할 때, 명확하지 않은 설계와 구상을 가지고 TDD에 따라 개발을 진행하게 되면, 요구사항이 자주 바뀌거나 적절하지 못한 테스트 케이스만 작성할 수 있어. 오히려 비효율적일 수 있다.

개인적인 TDD에 대한 생각.

😀TDD에 대해서 자세히 알아보기 전까지는 알송달송했다. 분명 test케이스를 먼저 작성하는 방법이라는 것은 알고는 있었지만, 나와 같은 주니어의 입장에서 반복숙달된 간단한 CRUD가 아닌 완전히 새로운 기능에 대한 적용이 생기는 경우라면 어떻게 TDD를 실행할 수 있지? 라는 의문점이 항상 남았었다.

최근 테스트 코드를 작성하면서 외부에서 가져다 쓴 코드에 대한 겨우 한줄의 테스트 커버리지를 채우기 위해서 3~4시간을 구글을 뒤져본 적도 있다. 하지만 TDD의 단점에 대해서 알아보면서 '아 내가 생각한 부분이 정확히 단점에 존재하는구나'를 느꼇고, 아직은 내 지식이 모자라 위와 같은 경우를 겪었지만, 분명 지금도 테스트 코드를 작성하면서 이 부분은 TDD로 작성했다면 좀 더 깔끔하게 작성할 수 있지 않았을까? 와 같은 생각을 한다.

현재 테스트 코드를 작성하면 리펙토링 해야할 코드가 눈에 보이는게 TDD를 적용했다면 처음 코드를 쓰면서부터 깔끔하게 쓸수 있었을텐데.. 이러한 부분은 굳이 작성하지 않아도 됬을텐데와 같은 생산성에 비효율적인 부분이 지금 눈에 밟히는게 이번 포스팅을 작성하면서 TDD가 정말 괜찮은 방법론이라는 것을 느낄 수 있었다.

참고자료(출처)
Kent C. Dodds 블로그 포스팅 When I follow TDD
whizlabs 블로그 포스팅 What is TDD and its phases?