TDD (Test Driven Development) 란?

TDD는 어떤 상황에서 해야할까

어떤 부분에 대한 코딩을 여러번 해봤고 결과가 어떻게 나올지 뻔하다면 TDD를 하지 않아도 된다. 또한 TDD를 했을 때 얻는 것이 적다면 하지 않아도 된다.

 

그렇다면 어떤 상황에서 해야할까?

 

1) 처음 해보는 프로그램 주제 

- 나에 대한 불확실성이 높은 경우

 

2) 고객의 요구조건이 바뀔 수 있는 프로젝트

- 외부적인 불확실성이 높은 경우

 

3) 개발하는 중에 코드를 많이 바꿔야 된다고 생각하는 경우

4) 내가 개발하고 나서 이 코드를 누가 유지보수할지 모르는 경우

 

즉, 불확실성이 높을 때 TDD를 하면 된다.

 

 

 

TDD의 효과 

 

'test'가 저장되면 남들에게 테스트 코드를 보여줄 수 있고, 남들은 그 코드를 직접 실행해 볼 수 있다. 즉, record로 남을 수 있게 된다.

 

그렇다면 TDD는 왜 협력을 증진시키는가?

 

이 record를 공유하면 협력이 증진된다.

- 남이 짠 코드를 빨리, 쉽게 이해할 수 있다.

- 내가 남의 코드를 고쳐서 문제가 있더라도 자동화된 테스트가 알려주기 때문에 큰 걱정없이 고칠 수 있는 용기가 생긴다.

 

즉, 왜 이렇게 짰을까????? 궁금할 때 'test'를 공유하고 그 테스트 코드를 보면 이해할 수 있다.

테스트 코드에는 개발자의 개발과정 (어떤 고민, 어떤 의사결정) 이 나와있기 때문이다.

테스트 코드를 보면 그 사람의 의사결정이 나타나고 상대방은 그 부분을 왜 그렇게 짰는지를 쉽고 빨리 알게 되기 때문에 협력이 증진된다.

 

 

 

TDD의 장단점

 

1. 개발 시간이 TDD를 하지 않을 때에 비해 대략 10~30%가 늘어난다.

 

2. TDD를 하면 결함이 1/2 ~ 1/10 까지도 줄어든다.

SW를 개발하면서 예상하지 못했던 시간을 많이 소요하는 것은 대부분이 버그 때문이다.

TDD를 하면 이런 버그를 줄일 수 있다.

 

3. TDD를 하면 코드 복잡도가 떨어진다.

- 엔트로피(Entropie)가 낮아진다.

- 깨끗한 코드가 나온다.

- 유지보수 비용이 낮아진다.

 

cf. 복잡도에 대한 재미있는 연구

- 들여쓰기(Indent)가 많은 코드는 복잡한 코드이다.

-  복잡도가 높으면 버그 숫자가 줄지 않는다고 한다.

 

 

 

왜 다들 TDD를 활용하지 못하는 걸까?

 

1. 개발 시간이 증가한다.

- 전체 개발 시간을 줄이는 것보다 오늘 일을 끝내는 것을 강조하기 때문에 TDD 도입이 어렵다. (단기적인 것에 집중되어 있으니.. 그때가서 또 고치면 되니깐.. 급한 불을 끄기에 급급..)

 

2. TDD가 어렵다.

- 왜? 이제까지 자신이 개발하던 방식을 많이 바꿔야 하기 때문에

- 몸에 체득한 것이 많을수록 바꾸기가 어렵다.

 * Unlearning - 이미 배운것을 까먹는 과정

- TDD는 오히려 개발을 별로 안해본 사람에겐 적용하기가 쉽다.

 

3. TDD는 이렇게 해야된다는 이미지/틀이 있다.(핵심)
‘반드시 툴(단위 테스트 프레임워크)을 써서 이렇게 해야된다.’라고 생각한다.
하지만 이런 규칙에 얽매이는 것은 애자일이 아니다.
결국엔 규칙에 얽매여 똑같은 테스트를 copy&paste 한다.
너무 도구/규칙에 집착하니까 TDD가 어려워지는 것이다.

 

 

 

 

TDD를 잘하는 방법?

 

- 나 스스로 '어떻게 해야 피드백을 더 자주 받을까', '어떻게 해야 내가 하는 작업에 대해 협력이 잘 일어나게 할까'를 고민하면서 계속해서 내가 일하는 방식을 업그레이드 해야한다.

 

- 예를 들어, 게임을 개발하면서 stage 3을 테스트할 때

항상 stage 1, stage 2를 클리어한 후 테스트를 해야 한다. -> 테스트 비용이 증가한다. -> 어떻게 하면 테스트 비용을 낮출수 있을까를 고민한다. -> 바로 stage 3으로 갈 수 있도록 만든다. -> 피드백을 값싸게 더 자주 받을 수 있다.

 

* 백도어 접근법: 테스트할 때 어떤 파라미터를 적용하면 내가 원하는 시스템의 시작점으로 가게 하는 것
이렇게 중복적으로 하는 노력들을 조금 더 자동화하도록 업그레이드하면 발전할 수 있다.

 

 

 

 

TDD에 대해 필자의 느낀점

역시 개발자들의 생각 패턴은 전부 똑같은 것 같다..
일단 실행되게 하는 것에 급급하고 생각을 하지 않고 코딩을 하다보면 언젠가 치명적인 단점을 초래한다.

나도 학부시절에 프로젝트를 진행할 때 얼른 내 분량을 결과적으로 '완성시키는 것'에만 집중했던 것 같다.
학부 프로젝트는 어쩔 수 없긴 하다. 누군가 나중에 유지보수를 하는 것이 아니니..
하지만 내가 진행했던 카페 좌석 서비스 어플리케이션같은 경우에는 내가 해당 프로젝트가 종료되고 난 후에도 좀 더 상용화를 목적으로 전문적으로 발전시키고 싶은 생각도 가지고 있었다. 하지만 그 후론 거들떠 보지도 않는다.

개발하면서 과정에 대한 문서화를 시키지 않았고 테스트 record를 남기지 않았기 때문이다.

이런 습관은 내가 이제 회사에 가서 개발을 함에 있어서도 매우매우매우 중요할 것 같다..

 

 

 

 

 

 

 

참조 

https://gmlwjd9405.github.io/2018/06/03/agile-tdd.html