TDD 적용기

TDD라기 보다는 테스트를 꼼꼼히 한번 짜봤다고 해야 할까. 좋은 점은 안정감이다. 코드를 여러군데 수정해도 테스트 코드가 있으니 안심이 된다. 과감하게 리팩토링을 할 수 있게 됐다. '테스트 없이는 리팩토링도 없다’는 말을 몸소 체득하게 된 것. 앞으로 나는 테스트 없이 개발을 하지 못할 것 같다.

왜 이렇게 테스트를 짜는데 망설여 왔을까? 테스트의 중요성에 대해서는 누누이 들었다. 여기저기서 읽기도 하고 신입교육 때도 들었다. 스프링 개발을 할 때는 어설프게 짠 적이 있었지만 커버리지가 매우 낮았다.

이유는 내가 앱 개발을 하고 있기 때문인 것 같다. 급박한 일정에 쫓기다보면 뷰 컨트롤러가 비대해지기 마련인데 이 경우 테스트 코드를 짜기 쉽지 않다. 뷰를 처리하는 로직이 다른 것과 섞여 그렇다. 

결과적으로 테스트 코드를 짜고자 하는 노력은 어떻게 하면 SOLID 원칙을 충실히 따르면서 구조화된 코드를 짤 수 있을까 하는 고민으로 이어졌다. Clean Code(로버트 마틴), Refactoring(마틴 파울러), 구현 패턴(켄트 백) 등의 서적을 열심히 탐독하고 있다. 여기에 헤드 퍼스트 디자인 패턴도 같이 읽고 있다. 

- 

로버트 마틴의 Clean Coder에서는 TDD의 세 가지 법칙을 다음과 같이 소개한다.

1. 실패한 단위 테스트를 만들기 전에는 제품 코드를 만들지 않는다.

2. 컴파일이 안 되거나 실패한 단위 테스트가 있으면 더 이상 단위 테스트를 만들지 않는다.

3. 실패한 단위 테스트를 통과하는 이상의 제품 코드는 만들지 않는다.

실무에 적용해보니 이는 매우 유용하다.

-

같은 책에서는 확신, 결함 주입 비율, 용기, 문서화, 설계 등을 TDD의 장점으로 꼽는다. 내가 이미 느끼는 바가 책에 쓰여 있어 반가웠고 더욱 확신이 들었다. 

특히 설계에 있어 많은 효용을 가져다주는 것 같다. 테스트를 하기 위해서는 함수가 public 상태로 실행될 수 있어야 한다. 이를 만족시키기 위해서 고민하다 보면 자연스레 설계가 좋아지는 것 같다.