About TDD

후배의 블로그에서 TDD에 대해서 글이 보이는 고로...

참고 도서: 테스트 주도 개발 : Test-Driven Development

위의 도서는 최근에 산 것중 하나로 TDD에 대해 이해하기 쉽게 쓴 책이라 할 수 있다. (서평 올려줘야 하는데 강컴은 서평 링크가 안되네) 나름대로 읽을 만한 책이니 빌려서라도 보시라...

TDD (Test Driven Development) 자체만을 놓고 본다면 지속적인 테스트 케이스가 제작되면서 프로젝트가 진행이 되기 때문에 상당히 견고하게 개발할 수 있는 방법론(이론적인 방법론하고는 거리가 멀긴 하지?으로 평가 할 수 있다. 프로그램이 일단 완성이 되는 순간 100% 동작할것이라는 환상에 대해서는 주의해야 하겠지만 소규묘 혹은 모듈단위 테스팅이 지속적으로 이루어 지고 테스트 케이스의 상당수가 같이 제작되는 방법이기에 권장될만 하다.

단점이라고 지적할 수 있는 부분은 실제로 적용해 보는 개발자들이 주로 하는 말이지만 "귀찮다"와 프로젝트 막바지에 이르러서는 너무나 해야 할 것이 많다는 것이다. 당연할 것이다. TDD는 Windows NT Kernel같은 대형 프로젝트 전체를 커버하려는 것은 아니기 때문일 것이다. 또다른 이유는 TDD로 100%의 검증을 시도해서는 안되기 때문일 것이다. 원자력 발전소에 들어가는 프로그램이 아닌이상 Zero-Bug를 기대하는 것은 너무 많은 코스트가 든다라는 점을 간과해서는 안될것이다. 목표로 하는 수준의 퀄리티에 맞추어야 한다.


TDD 에 대하여 공부하면서 느낀 것중 하나는 Prototype Function이다. Red 상태를 일단 만드는 것을 중요시 하는데 그것은 일종의 Prototype 개념과 비슷하다라고 느겼다. 약 1k 근처의 프로그램을 작성할때 많은 사람들은 함수 하나하나를 완성해 나간다. A라는 함수를 완성하기 전에는 다음 함수를 진행하지 않는다. 초보자들이 main 함수 안에서 모든 것을 구현하는 것과 비슷하다. 반면 어느정도 숙달된 프로그래머들은 Top-Down 형식으로 적당한 역할을 하는 함수들이 있다고 할때 그것을 main에서 사용하고 다시 각각의 함수들을 만드는 형식으로 한다. 이쯤에서도 상당수의 사람들은 함수 하나를 완성하려고 하는데 사실 그보다는 각각의 함수를 조금씩 짜 나가는 것이 좋다. 인자를 받아서 그것의 Validation을 확인하는 코드까지 한번에 짜려고 하지 말고 일단 처리하는 코드를 대충 짜고 그 다음 함수의 흐름을 계속 만들어 나가는 것이 효율적이다. 전체적으로 흐름이 완성되고 나면 그제서야 함수 하나하나에 대해서 디테일 하게 들어가는 것이 좋다. TDD에서는 이를 극단적으로 이용하는데 심지어 함수 내부에 아무것도 없이 임의의 리턴값을 내보내게 만들기도 한다.

아직 TDD를 실제 적용해서 프로젝트를 해본적은 없지만 여기 저기를 둘러보면서 개발자들이 가장 힘들어 할 부분이 100% 검증에 목매다는 것과 Red 상태에 대한 죄책감이 아닐가 한다. 프로그램의 안정성을 단지 TDD만으로 해결하려는 생각은 버려야 하고 또한 안정성과 코스트의 상관 관계에 대해서 생각해야 할 것이다. 그리고 개발 초기에 있어서는 함수의 완성이 중요한 것이 아니라 뼈대가 중요하며 Red 상태의 함수를 만드는 것이 중요한 작업이라는 것을 이해해야 할것으로 보인다.

~~~~~~~~~~~~~

제가 TDD에 대한 조예가 깊은 것은 아니니 글에 오류가 있다면 즉시 피드백을 주세요. :)