Extremely Agile/TDD2008.10.21 13:53
TDD를 배우고 실무에 적용해보고 나면, 프로그래머는 대략 다음 두 가지 중 하나의 유형으로 바뀝니다.

1. TDD를 굉장히 열정적으로 사용하는 프로그래머
2. 테스트의 필요성을 절감하고 테스트 케이스를 작성하긴 하는데, 그렇게 TDD를 열심히 하지는 않는 프로그래머

저는 이 중 어느쪽이냐 하면, 후자 쪽입니다. 아직 TDD에 확실히 익숙해지지 않아서 그럴 겁니다. 물론, 자기가 작성하는 코드에 대한 자신감이 높은 프로그래머도 두번째 유형에 속할 가능성이 높습니다. 이런 프로그래머는 TDD는 너무 오버헤드가 높은 방법이라고 느끼는 경향이 있습니다.

사용자 삽입 이미지

http://www.nilkanth.com/archives/2007/06/08/three-monkeys-of-test-driven-development/


그런데 두 번째 유형의 프로그래머들이 흔히 빠지는 함정이 하나 있습니다. 블랙박스 테스트(blackbox test)를 하게 될 가능성이죠.

보통 프로그램을 클래스 단위로 구분해서 작성하게 되면, 최소한 클래스가 하나 만들어 질 때 마다 테스트 케이스들을 만들도록 하는 것이 좋습니다. 그런데 프로그래머에 따라서는 클래스가 아니라, 모듈이 하나씩 만들어 질 때마다 테스트 케이스들을 작성하기도 합니다.

그렇게 하면 보통 모듈에 속한 모든 클래스들에 대해 테스트 케이스를 작성하기는 어려워집니다. 정말로 어려워서 어렵다는 것이 아니라 귀찮아서 생략할 가능성이 높아지기 때문에 어렵다고 하는 것이죠. 그렇게 되면 모듈의 관리자 클래스(Manager class)에 대한 테스트 케이스들만 만들어지게 됩니다. 모듈의 인터페이스에 대한 테스트 케이스만 만들어지게 된다는 것이죠.

결국 모듈이 블랙 박스가 됩니다.

블랙 박스 테스트가 의미가 없다는 뜻은 아닙니다. 하지만 추상화 단계의 위쪽으로 올라가 테스트를 하게 되면, 거기서 처리해야 할 테스트의 가짓수가 늘어나게 됩니다. 그 모든 경우를 다 따져 테스트 케이스를 작성하면 좋겠지만, 그렇게 못할 가능성이 높습니다.

결정적으로, 블랙 박스 테스트로는 "모듈의 어느 부분에서" 오류가 발생했는지를 감지하기가 어렵다는 문제도 있습니다. 그렇기 때문에 가급적 코드의 가장 작은 단위에 대해서부터 단위 테스트를 진행하는 것이 좋다는 것이죠.

TDD를 하지 않더라도 그렇게 하면 적어도 버그의 수를 줄이는 데는 도움이 되는 것을 경험했습니다. 거기다 부수적인 이득도 얻을 수 있는데, "테스트가 쉬운 코드를 만든다"는 목적은 그대로 유지할 수 있다는 겁니다. 물론 "테스트 코드를 통해 실제 코드의 디자인이 결정되는" 신기한 경험은 할 수 없겠지만 말이죠.
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^