들어가기 전에

일단 난 TDD를 할 능력도 안되고, 사수 개발자가 Test를 먼저 짜주어도 그걸 구현할지도 미지수이다.(우테캠 2차 과제테스트때 거의 구현하지 못했다) 그래도 나에게 TDD를 구현할 능력이 충분히 있다면 그때 TDD를 적용시킬 지에 대한 토론을 진행해보고자 한다.

TDD 찬성!

선배 개발자가 이끌어주기 좋아!

잘하는 선배 개발자가 테스트를 만들어주면, 후배 개발자는 이 테스트를 다 통과하는 코드만 작성하면 된다. 바로 알고리즘 구현 문제가 되버리는 거다. 난이도가 아주 높겠지만..

테스터의 입장까지 고려해볼 수 있어!

코드를 먼저 짜고 테스트를 작성한다면 코더의 입장으로 작성할 수 밖에 없다. 그러나 테스트를 먼저 작성하면 테스터의 입장으로 작성할 수 있어, 더 많은 테스트 케이스를 고려해볼 수 있을 것이다.

TDD 반대!

시간이 너무 오래걸려!

이건 찬성측, 반대측도 모두 동의하는 내용이다. 그냥 구현하는 것보다 시간이 오래걸린다. 단위 테스트를 생각하는 것만으로도 복잡한데, 이걸 구현까지 하라? 시간이 배로 걸리는 작업이다. 우리는 그렇게 한가하지 않고 TDD로 개발할 바엔 구현에 더 힘을 쓰는게 훨씬 효율적이다.

너무 어렵고 추상적이다!

TDD를 하기 위해선 테스트 코드를 먼저 작성해야 한다. 근데 구체적인 게 없고 상상만으로 필요한 것들을 선언하고, 목 객체를 만들고, 이를 테스트 하라? 이는 상상으로 여자친구를 만들고 실제 데이트처럼 하는 것 만큼이나 어려운 일이다. 왠만한 숙련자들이 아니고서야 해내기 힘들고, 나도 이걸 할 능력이 없다. 실제로도 우아한 형제들 팀들 중 TDD로 개발하는 팀은 소수이고, TDD하는 팀 마저 시니어 개발자들이 다수라고 한다. 그렇기에 TDD는 통용되기엔 너무 어려운 방법론이고, 너무 추상적이다.

판단은 여러분의 몫!

TDD는 좋은 품질의 코드를 만들 수 있는 좋은 방법론이다. 다만 너무 이상적이다. 마치 야채 많이 먹으면 건강해진다는 걸 알지만 야채 많이 먹기가 쉽지 않은 것처럼 말이다. 그렇기에 여러분의 기업, 부서, 팀에 맞게 좋은 방법론을 선택하길 바란다.