이번에 Javascript 과제로 deepClone 함수와, 내용이 같은 객체인지를 확인하는 isEqual 함수를 만들었다. 이때 선생님이 먼저 작성해 주신 테스트 코드로 테스트를 진행했는데, 그동안 겪어보지 못했던 편리함과 개발의 효율성을 몸으로 느낄 수 있었다. 그리고 이를 통해 테스트 코드를 먼저 작성 한 후 개발을 진행하는 개발 방법론이 있다고 해서 알아보았다.
TDD란 "Test Dreiven Developtment"의 약자로 테스트 주도 개발을 뜻한다. 소프트웨어 개발방법론 중 하나로 쉽게 말하면 테스트 코드를 먼저 작성 한 후 구현에 들어가는 것을 뜻한다.
TDD는 3단계로 구분된다. 테스트 코드 작성, 테스트 코드 통과를 위한 구현, 리팩토링으로 구분된다. 각 단계의 자세한 내용은 다음과 같다.
테스크 코드를 작성하는 단계는 흔히 RED 단계, 혹은 실패하는 코드 작성 단계로 말한다. 이 단계에서 테스트 코드를 작성하고 테스트가 실패하는지 확인한다. 실패하는 것이 확인 되어야 테스트가 검증력을 가지기 떄문이다. 또한 실패의 이유는 코드가 아직 작성되지 않았기 때문이어야 하지, 테스트 코드 자체의 문제여서는 안된다.
테스트 코드를 작성했다면, 이제 테스트를 통과하는 코드를 구현하면 된다. 이 단계는 흔히 GREEN 단계라고도 한다. 이때 중요한 포인트는, 테스트를 통과 할 수 있는 최소한의 코드만을 구현하는 것이다. 이미 작성된 테스트 코드를 기준으로 구현하며, 이때 부가적인 테스트 코드를 추가 하지 않는 것이 중요하다. 그렇지 않으면 오버엔지니어링 하게 될 확률이 높기 때문이다.
구현이 모든 끝난 후 진행하는 단계로, 흔히 YELLOW 단계라고도 한다. 구현 단계에서 테스트를 통과하기 위한 최소한의 코딩을 진행했다면, 이 단계에서 불필요한 중복을 없애는 등 코드의 질을 높일 수 있도록 코드를 수정한다. 리팩토링의 과정을 거치기 때문에, 구현 단계에서 너무 많은 시간을 쏟아붓지 않아도 되는 것이다.
TDD를 진행하면 최대한 작은 단위의 기능을 테스트하며 구현하게 된다. 이를 통해 코드가 방대해 지지 않고 코드의 모듈화가 자연스럽게 이루어 질 수 있다.
오버 엔지니어링을 막을 수 있다. TDD의 개발 절차에 대해 위에서도 설명했지만, 구현하는 단계에서 테스트 코드를 추가로 작성하지 않는다는 원칙이 있다. 이를 통해 필요 이상의 기능을 개발하지 않을 수 있게 되어 오버엔지니어링을 막을 수 있다.
유지보수가 용이해진다. 기존의 테스트 코드를 가지고 있다면 새로운 기능이 추가됨에 따라 기존 기능에 버그가 발생하는지를 확인 할 수 있다. 또한 테스트 코드는 사용설명서 혹은 API 문서로서 의사소통의 도구로 활용할 수 있다.
TDD 방법론은 무척이나 장점이 많은 개발론이다. 그러나 초기 투자비용이 많이 든다는 이유, 혹은 기존의 개발 방법과 다르다는 이유로 쉽사리 적용하지 못하는 개발자 혹은 회사가 많다고 한다.
만약 내가 당장 TDD의 절차에 따라 개발을 하지 못 할 상황이라고 한다면, 일단 테스트 코드를 작성하는 습관을 들이는게 어떨까 싶다. 테스트 코드를 작성하는 습관을 길러보고 테스트 코드를 아카이빙 한다면, 결국 더 탄탄한 코드를 만들 수 있는 개발자가 될 수 있으리라고 생각한다.