TDD

Test Driven Development 의 약자로 테스트 주도 개발이라는 뜻이다.

기존에는 폭포수방식이라고해서 설계가 진행되면 구현, 구현 후 테스트, 테스트 후 인수 이런 방식으로 일단 설계한대로 모든 개발이 끝나고나면 테스트를 진행하는 방식이었는데 이런식으로 하다보니 에러가 발생했을때 해당 에러를 찾고, 수정하는데 있어 소모되는 시간과 비용이 너무 커져 이를 바꿔보고자하고 나온것이다.

개발이 완료되면 테스트를 하는것이 아니라 구현의 가장 아랫부분인 메서드 구현단계부터 지속적인 테스트를 통해 개발을 함으로서 지속적인 테스트를 하게되고 문제점을 보다 빨리 찾아내어 적은 비용으로 에러를 처리하고 완성도높은 소프트웨어를 개발하고자 하는것이다.

'주도'라는 단어에 좀 더 집중을 해야하는데 메서드를 구현한 후 테스트를 진행하는것이 아니라 아주 처음부터 테스트를 진행하면서 완성된 메서드를 구현하는것이다.

그렇기에 처음 접하게되는경우에는 이게 뭐하는 짓인가 할정도로 의미없어보이는짓 같기도하지만 1분안팎을 주기로 지속적으로 테스트를하며 그 리듬에 몸을 얹어(?) 개발하는 기법이다. 또한 테스트를 진행하며 메서드를 완성한 후에는 리팩토링을 통해 마무리를 하게되는데 TDD의 주기는 이렇다.

테스트 => 실패 => 수정 => 성공 => 리팩토링

일단 시작부터 실패로 시작하기때문에 위에서 말한대로 의미없어보이는 경우도있을것이고 그런 작은 보폭으로 개발을 하는것이 처음에는 익숙치 않을수 있으나 지속적인 연습을 통해 몸에 익히게되면 좀 더 고품질의 코드를 얻을수있지않을까 한다. 아래와같은 TDD 원칙을 꼭 숙지하자

-실패하는 테스트를 작성하기 전에 성공코드를 작성하지 않는다.

-실패하는 테스트는 하나씩만 작성한다.

-현재 실패하고있는 테스트를 통과하는 수준 이상의 코드를 작성하지 않는다.

추가

요즘들어 면접을 자주 다니고있는데 TDD에 대한 얘기를 할때면 거의 빠지지않고 '테스트 코트가 길어지면어떡하나?', '100줄짜리 코드를 테스트하기위해 200줄짜리 테스트코드를 짜야하나?' 이런식의 질문이 나온다. TDD는 개발하는데 추가적인 시간이 소모되는 개발방법이다. 30초~1분을 주기로 계속해서 테스트를 돌려야하니 당연하지않은가? 하지만 그로인해 쌓이는 테스트케이스들은 개발완료후 리팩토링을 위해 소스의 구조를 바꿔야하는경우, 기능추가 등의 요구사항이 들이 닥쳤을때 소중한 자산이 될것이며 사이드이펙트(부작용)를 예방할수있는 좋은 예방주사가 될것이다. 각종 테스트중에서도 가장 예측하기힘들고 테스트하기도 귀찮고 어려운게 회귀테스트인데 테스트케이스만 잘 갖춰져있으면 테스트에 스트레스받을일이 줄어들기때문이다. 또한 100줄짜리 코드를 테스트하기위해 200줄짜리 코드가 필요한 모듈이라면 그만큼 의존하는 부분이 많고 중요한 로직일것이기에 두고두고 테스트할일이 많아질것이다. 그런걸 생각한다면 그때마다 한줄 수정하고 직접 테스트하느라 시간보내는것보다 처음에 200줄짜리 코드를 만들어놓는다면 오랜시간 마음이 편해질것이기에 에러가 좀 있더라도 빠르게 프로토타입을 내놓아야하는 경우가 아니라면 TDD는 도입하는게 좋다고 본다.