TDD에게서 자유로워 지자

2000년대 중후반은 모두가 유닛 테스트에 미쳤다. 아니 TDD에 미쳤다.

Test Driven Development에 대한 서적이 넘쳐났으며, 모두가 TDD를 통해 구원 받을거라는 희망찬 상상에 들떠 있었다.

이 붐을 주도했던 개발자중 한명인 DHH (rails를 만든 이)도 이 흐름에 동참했었다. 

그를 비롯한 많은 이의 주장은 테스트 우선 신앙 (Test first fundamentalism)라 불릴 만큼 테스트를 바탕으로 코드를 작성하면 그 퀄리티가 비약적으로 상승 할 것이라는 의견이었다.

여지껏 내가 해온 테스트는 다음과 같았다.

독립적으로 동작할 수 있는 클래스에 대한 유닛테스트.

- 화이트 박스 테스트로써의 유닛 테스트. (나는 크게 선호하진 않았지만, 가끔 진행했고 유닛테스트를 실천한 초반에 특히 많이 진행했다.)

- 블랙박스 테스트로써의 유닛 테스트. (블랙박스 테스트를 난 매우 선호했는데, 외부에서 사용하는 메소드야 말로 기대치대로 동작하는지 검증되어야 한다고 믿고 있고, 그 믿음에 대해선 변함이 없다.)

외부 프로세스 내지는, 외부 입력을 시뮬레이션 해서 진행하는 컴포넌트 테스트

- input이 패킷이 주가 되는 서버 프로그램의 경우에는, 시뮬레이터 내지는 테스트 클라이언트라 불리우는 어플리케이션을 통한 테스트.

외부 입력을 통한 부하 테스트

- 프로파일링을 겸한, 임계치 측정 및 검증.

- 부하 발생시의 안정성에 대한 검증.

위 테스트중 유닛테스트는 일일 빌드를 통해 검증

컴포넌트 테스트는 업무시간 도중에.

부하테스트는 퇴근하고 난 이후부터 익일까지.

이런식으로 시간을 나누어 관리했다.

헌데 이렇다보니, 컨텐츠 개발하고 버그에 쫓기고 하다보면 막상 테스트를 들여다보고 개선하고, 테스트 코드를 추가하는 일이 만만치 않았다.

당연히 개발 후 테스트 코드 추가보다 더 오래 걸리는, 테스트를 추가하며 기능을 검증하는 일. 즉 테스트 주도 개발과는 거리가 멀게 개발해오고 있었고, 심적으로 매우 불편했다.

꼭 안생겨도 될 버그를, 시간을 조금만 더 쓰면 커버리지를 갖출 수 있는 상황을, 테스트 주도 개발을 외면하면서 맞이한게 아닐까 하는 생각이었다.

이런 생각을 이사님과 토의한적이 있었고, 이사님은 비용이 많이 드는 테스트에 대한 부정적인 의견을 피력하셨다.

"테스트를 작성하기 위한 비용이 너무 크다면, 테스트 코드를 작성하는 것마저 낭비라고 생각한다."

테스트 코드가 주는 이득을 많이 체감했던지라 나는 당시 크게 공감하진 못했다. 특히나 이 말을 하신 이사님은 테스트 코드 추가를 위해 많은 비용을 감내하시고, 여러 객체의 mocking과 단위 테스트, 시뮬레이트 코드를 위해 시간을 많이 쏟으신 분이셔서 더더욱 놀랐었다.

헌데 DHH의 고백을 읽고나서 다시금 떠올려본 이사님의 말은 나에게 큰 공감을 가져다 주었다.

가장 크게 와닿은 단락은 아래와 같다.

• 두번째 단계는, unit 부터 system 사이의 테스팅 스펙트럼의 균형을 잡는 것이다.

그렇다! TDD는 유닛 테스트의 중요성만을 지나치게 강조해왔다.

유닛테스트를 통해 해당 클래스의 단독 동작은 보장되지만, 여러개의 클래스가 mocking 없이 묶였을 때의, 다양한 입력과 다양한 상태(state)에서의 출력(동작)은 보장하지 않는다.

실제로 이 부분을 커버하기 위해 나는 컴포넌트 테스트라 불리우는 (시스템 테스트라는 용어가 있는지 이제 알았다. 나도 앞으로 이렇게 써야겠다.) 시스템 테스트를 해오긴했으나, 유닛 테스트를 위한 시간 투자를 덜한다는 찜찜한 마음은 버릴 수 없었다.

하지만 이제 편해졌다.

너무나 당연한 얘기지만 시간은 돈이다. 테스트를 작성하기 위한 시간도 돈이고, 테스트를 유지하기 위한 비용도 돈이다. mocking을 위해, 혼자 일때만 잘 동작할지도 모르는 녀석을 위한 시간낭비가 될 수도 있는 유닛 테스트를 위해 강박을 가질 필요까진 없다.

물론 DHH의 이야기도 테스트의 중요성을, 매우 강조한다. 하지만 테스트 "주도" 개발은 하지 않고 있다는 것을 고백했다.

테스트 "주도" 개발이 얼마나 느리고, 비효율적이며, 그 성과가 미약했음을 고백한 것이라고 볼 수 있다.

이런 얘기가 다른 사람도 아닌 DHH에게서 나온 것은 너무나도 반갑다.

테스트 코드나 테스트를 줄이자는 얘기가 아니라는 것은 다들 알 것이다.

유닛 테스트와 시스템 테스트간의 밸런스를 맞추고, 테스트에 대한 투자 대비 효율에 대해 지금보다 심도 있게 고민해보자.

그리고 TDD에선 자유로워 지자!

TDD는 죽었다 - Rails를 만든 DHH의 글

http://yisangwook.tumblr.com/post/83725422949/tdd-is-dead-long-live-testing

TDD is dead. Long live testing. (DHH) — likelink

http://likelink.co.kr/29242