라벨이 TDD인 게시물 표시

테스트 얼마나 만들어야 할까?

에자일한 소프트웨어를 만드는 방법의 하나로 TDD 에서는 test를 먼저 작성하는 것을 권장? 혹은 강요한다. 스펙에 맞춰 테스트를 하나하나 만들어가고, 그 테스트 케이스들을 초록색으로 만드는 것을 반복해 나가다 보면 에러 없는 코드가 완성된다는 것이다. 이 방법론에 대해 비난할 생각은 없다. 매우 좋은 방법이다. 근데 정말로 언제나 해야 하는 걸까? 부작용은 없을까? 내가 이것들에 대해 고민하게 된 것은 TDD를 처음 배우고 Rails를 사용하고 있던 3년 전 일이다. 그전에 했던 프로젝트가 C++로 서버를 만드는 일이었고 사소한 예외처리 몇 개를 실수해서 몇 일 밤을 새웠던 직후라서 더욱더 테스트에 매달리게 되었다. 다행히도 rails는 유닛테스트에 특화된 framework이었고 (당시에 DB까지 unit test가 가능하도록 지원해주는 framework이 얼마 없었다.), TDD의 원칙에 따라서 많은 테스트와 함께 코드를 작성해 나갔다. 그렇게 가끔 테스트가 없었으면 크게 삽질했을 버그를 잡아가면서, 그 프로젝는 내가 질릴 때까지 별문제 없이 진행되었다. 여기까지만 보면 TDD의 긍정적인 사례에 추가될 수 있을 것 같지만, 실상은 전혀 아니었다. 문제는 두 가지가 있었다. 첫 번째는 테스트 작성에 심취해서 개발에 너무 많은 시간이 들었다는 것이고, 두 번째는 너무 빨리 질렸다는 것이다. 당시에는 아직 TDD에 적응이 안 돼서라고 생각했는데, 정도의 차이가 있었지만 2번째 프로젝트에서도 비슷한 현상이 나타났다. 왜 그렇게 된 것일까? 이것에 대해 고민하다가 RubyOnRails의 제작자인 David Heinemeier Hansson의 글 을 보게 되었다. 논쟁이 많이 되었던 글이지만 David가 말하고자 하는 바는 단순하다. 테스트를 작성하는데 들어가는 비용도 기능 구현이나 디버깅에 들어가는 것과 같은 비용이니 overtest하지 않도록 노력해야 한다는 것이다. Unittest라는 도구를 처음 접해 아무 생각 없이 심취해버렸던 나는, test를

이 블로그의 인기 게시물

[C++] enum class - 안전하고 쓰기 쉬운 enum

RAII는 무엇인가

Log Aggregator 비교 - Scribe, Flume, Fluentd, logstash

[Python] cache 데코레이터로 최적화하기

[Web] SpeechSynthesis - TTS API