TDD가 가져온 변화


지난 기간동안 TDD를 도입하며 느꼈던 부분들을 공유하고자 한다. TDD가 주는 이점은 분명히 존재하지만 TDD를 꼭 도입해야 하느냐에 대한 원론적인 내용은 아니며, 사전 테스트가 지니는 의미에 중점을 두고 작성해 보았다.


Pre-Test는 꼭 필요한가?

보통 개발자들은 구현된 로직의 결과에 집중하는 테스트를 작성하는 것에 익숙해져 있다. 예를 들면, sum(a, b)라는 가산 행위가 존재하고 이에 대한 테스트 케이스를 input argument와 output을 통해 비교하는 기계적인 테스트가 반복되는데, 이는 결국 행위의 결과에만 맞추어지는 맞춤형(?) 테스트가 될 가능성이 굉장히 높다. 실제 가산이라는 행위 자체에 촛점이 맞추어진 것이 아니라 행위의 결과에 대한 기대치에만 집중된 테스트라는 얘기이다. 이런 테스트는 자주적인 리팩터링을 추구하는 개발자가 스스로 욕심을 내지 않는 이상, 가산 로직이 더 유연하고 단단해질 기회를 만들어 주지 못한다. 아무리 테스트 커버리지가 높은 수준을 유지하더라도 좋은 코드 품질의 기준으로 보기에는 어렵다.
하지만 사전 테스트 케이스를 작성함으로서 개발자는 스스로 행위 로직에 대한 설계에 더 신경을 쓰게 된다. 실패하는 테스트를 먼저 만듦으로서 좀 더 투명하고 직관적인 인터페이스를 설계할 수 있게 되고, 결과값이 아닌 로직 자체에 더 신경쓰게 된다. 이렇듯 행위는 자연스레 원자적이고 응집성 높게 다듬어지며 재사용성을 높게 만들고 객체 언어를 사용하는 개발자라면 -Object Oriented-한 코딩 습관을 길러주는 계기가 된다.
이렇게 개발된 코드는 요구사항의 변화에도 능동적이다. 튼튼하게 설계된 행위는 기능 자체가 완전히 뒤바뀌지 않는 이상 수정 사항을 반영하기가 훨씬 수월하며 이는 결국 코드의 신뢰성을 판단짓는 밑거름이 된다.
결국 사전 테스트가 가져오는 가장 큰 변화는 코드를 작성함에 있어서 얼마만큼 디자인과 행위에 더 고민하느냐로 시작된다.


개발 일정의 변화

재미있게도 개발과 테스트 케이스 작성을 별개로 생각하던 개발자들이 자연스럽게 테스트 주도 개발을 실천하며 앞서 두 가지를 하나의 개발 흐름으로 받아들이는 모습을 보인다. 찍어내듯 뽑아내는 테스트 케이스(특히 폭포수 개발을 하는 곳에서 많이 나타난다) 때문에 프로젝트 오픈 이전의 노가다 작업들은 확실히 줄어들었다. 몰아서 만드는 테스트 케이스보다 시작부터 주도적으로 만드는 테스트 케이스의 개발 리듬이 정착되다 보니, 적어도 테스트 케이스 작성까지 고려하여 산출하던 개발 일정은 어느 정도 단축이 가능했고 이는 곧 개발 속도가 전반적으로 탄력있게 변했다는 것이라 생각이 든다.


Agile하고도 잘 맞네!

점진적이고 주기적인 반복 개발 방법론을 실천하고 있다면 TDD가 더없이 어울린다. 반복 주기별 요구사항은 사전 테스트 케이스가 그 출발점이 되고 다양한 형태로 문서화되어 배포될 수 있다. 이러한 장점은 -행위 주도 개발(이하 BDD)-를 적용하는데 있어서 좋은 구실점이 될 수 있다. 또한 반복적인 TDD + Refactoring이 주는 이득은 전반적인 개발 과정을 유연하게 만들어주고 애자일 방법론에 더욱 힘을 실어준다.


Conclusion

TDD는 보통 환경적인 제약에 의해 실천하기 어려운 경우가 많다. 결과물과 일정만으로 실적을 반영하는 현업을 설득하기가 정말 어려울 수 있고, 무엇보다 수동적인 개발자들이 많다면 더욱 그렇다. 하지만 한번 시작하면... 빠져나오기 어렵다 -0-;;


'TODO: blah blah~' 카테고리의 다른 글

Summary of HTTP/2  (0) 2015.04.21
Mixed Scala and Java Project 구성하기  (0) 2015.03.12
TDD가 가져온 변화  (0) 2015.02.11
Java 8 - Method References  (0) 2014.09.15
Java 8 - Lambda Expression과 변경된 Interface의 모호함  (0) 2014.09.09
Java 8 - Metaspace Area  (0) 2014.06.02