[TDD] 이틀째 - 생산성이 떨어진다

분류없음 2009.01.17 11:34
TDD에 대한 얄팍한 지식만을 일단 습득하고 실전에 적용해 보고 있다.
업무에 적용하기에는 너무 위험성이 높은지라 주말 프로젝트에 적용중이다.
일종의 단순한 윈도우즈 커널 드라이버를 만드는 중인데, 커널 드라이버에서 꺼내려는 데이타의 길이가 동적이라서 만약 입력된 버퍼의 길이가 불충분하면 "Insufficient Buffer"라는 에러 코드를 내어 주고 얼마의 버퍼가 필요한지를 알려 주게 된다.

단순한 코드이다.

그런데, TDD를 사용하니 복잡한 코드가 되고 있다.

실제 커널드라이버의 코드 수정은 단지 5-6줄을 바꿔 가며 디버깅을 한 반면, 테스트 코드는 순식간에 20-30줄을 넘어 가 버린다. 모든 상황을 생각해서 일단 Fail을 해야 다음으로 넘어 갈 수 있기 때문에 어쩔 수 없다.

일단 시작하자 마자 생산성은 확 떨어진다.

하지만, 전에도 말했듯이 컴파일러가 신택스 에러를 잡아 주듯이.
잠재적인 논리 에러를 잡아 줄 장치를 같이 만들고 있기 때문에 일단 테스트에 패스하면, 굉장히 내 코드에 대해서 자신감이 생기는 것 같다.

업무상의 코딩에서 한번 씩 내 발목을 잡았던 버그들을 생각해보면 대부분 예외 상황을 고려 하지 않고, 이럴 경우에는 이것이다라는 단순한 논리만으로 작성한 경우가 많았다. 예외 상황 한번이면 그러한 논리는 여지 없이 버그라는 형태로 박살이 나고 말았다. 그러다 보면 코드 위에 덕지 덕지 수정을 가하고 다시 기나긴 테스트를 거치고 하는 과정을 서너번 거쳐야 할 경우도 있다.

결국 TDD가 내 실제 업무 코딩에도 도움을 줄것이라고 확신한다.

다만, 그 적용을 얼마나 센스있게 하느냐와 테스트 과정을 얼마나 자동화하고 단순화 하느냐, 또한 테스트 코드를 얼마나 똑똑하게 짜느냐 등등이 관건인듯 하다.

특히 업무상의 코딩의 경우 데이타 처리가 대부분 패킷이고, 작동 공간도 커널 공간이라든지 하기 때문에 정말 테스트가 쉽지 않다. 각각의 경우에 어떻게 테스트를 효율적으로 수행할지에 대해서도 많은 고민이 필요할듯 하다.

일단 오늘은 이 정도...

Posted via email from bugtruck's posterous

신고
◀ PREV : [1] : ... [3] : [4] : [5] : [6] : [7] : [8] : [9] : [10] : [11] : ... [158] : NEXT ▶

티스토리 툴바