이번에 중규모 팀 프로젝트를 TDD로 진행해보고 느낀점임. 사실 나 포함 팀원들 모두 부정적이었는데 메이저 기능을 개발하는 작업이 아닌지라 그래도 한번 해보고 결정하자 라는 마음으로 진행했음.

결론적으로 느낀점은 레딧이나 해외 개발자 커뮤니티에서도 TDD는 버려지는 추세인데, 여기에는 이유가 있음.

- 유닛 테스트는 어떻게 기능 적용할 건지 확실한 상태에서 완성되는 건데, TDD는 본질적으로 선 테스트 후 기능개발 이기 때문에, 현실적으로 결국에 처음 적은 테스팅을 나중에는 다시써야해서 시간적 단축이 안됨. 덧붙여 설명하자면, 모든 것이 완벽한 이상적인 시스템에선 이게 가능하겠지. 기획이 완벽에 가깝고 사전에 개발자들이 한곳에 모여 정리를 할 수 있는 인력 여력과 시간이 된다면. 문제는 TDD 근본 자체가 최근 프로젝트 관리 트랜드인 에자일이랑 서로 상충한다는 거임.




TDD와 함께 에자일 방식을 채택하게 되면, 디자인 페이즈를 버리고 프로젝트를 진행해야하는데, 위의 과정중에 프로덕션 단계에서의 테스트 리팩토링이라는 요소가 하나 더 추가되게 됨.

당연히 디자인이 변경되었을 때 이 테스트 리팩토링은 리팩토링이 아니라 코드를 다시 써야하는 시간으로 변질되게 되어있고, 이러면 에자일이 근본적으로 추구하는 기능개발을 가볍게 가져간다 라는 장점이 죽어버림.


디자인 페이즈를 안가져가면 생기게 되는 문제는 다음과 같아.


- 개발을 하다보면 반드시 빼먹는 부분이 생김. 큐잉 매커니즘이나 알고리즘 같은 부분에 있어서 항상 빵꾸가 생기는데, 이런 부분이 있을 때 마다 코드 수정범위가 많아짐. 애초에 좋은 코드를 작성하려는 이유가 관리 포인트를 집약시키기 위해선데 이게 막상 TDD 에서는 더 힘들어짐.


- 유닛테스트 작성시에는 필연적으로 데이터 부분에 있어서 mock을 만들어야 해서 유닛 테스트만으로 해결할 수 있는 범위가 제한되어있음 (API 쪽)


- 상품 개발에 있어서 기획은 반드시 변경되게 되어있음 (고로 에자일이 대세가 된 이유)


무엇보다... 테스팅을 통과시킨다고 해서 코드의 질이 좋아지는게 아님.


따라서 TDD를 효율적으로 진행하려면 강제적으로 워터폴 방식을 채택해야함.

테스트 자체가 나쁘다가 아니라, 돈을 버는게 목적인 회사에서는 항상 비용, 질, 시간 사이에서 균형을 잡아가야하는데 뿌리부터 특정 개발 방법론을 강제하는 TDD는 근본적으로 이러한 균형을 유연하게 가져갈 수가 없음.


결론적으로 테스트 방법론으로써 내가 권장하는 것은 BDD 방법론을 채택하는 거임. 각각의 유닛 테스팅을 작성하는 것이 아니라 E2E 테스팅처럼 하나의 시나리오(스토리)를 만들고 이 플로우 자체를 테스팅 하는거지. 웹 개발을 예로들어 간단히 얘기하자면 e2e 테스팅이나, Postman 같은 툴을 생각하면 됨.


그러면 모든 함수나 메소드에 대해서 테스팅을 작성할 필요가 없고, 시스템의 안정도를 100%는 아니지만 코어 기능의 정상 작동여부에 대해서는 보장할 수 있게 되며, 가장 중요한 개발 시간이 많이 아껴짐.