<< 기업 프로세스에서 일어나는 흔한 현상들 | Home | 맥도날드 이론 >>

TDD에 관한 비용적인 관점

Ruby on Rails의 창시자 David가 TDD에 대해 비용의식에 대해서 쓴 내용(Testing like the TSA from 37signals)이 있어 정리해 봅니다. TDD에 대한 가치는 분명히 있지만, 무조건적인 옹호보다는 TDD의 비용 인식을 통해 합리적 대안을 찾아서 TDD를 수행하는 것도 괜찮아 보입니다.

먼저, 개발자는 테스트 주도 개발(TDD)의 놀라움을 발견했을 때, 우리들은 스트레스나 불안이 적은, 새롭고 더 좋은 세계의 입구에 들어선 것과 같은 기분이 들었을 것이다. 정말로 그것은 축복받을 만한 가치있는 좋은 경험이다. 그러나 테스트의 이득을 자신의 것(내재화)으로 하는 것은 깨달음의 첫 단계에 불과하다. 무엇을 테스트하지 말아야 하는 것을 아는 것은 더 어려운 일이다.

초보자인 당신이 첫날부터 무엇을 테스트하지 말아야할지를 신경쓸 필요는 없다. 그 다음 2일째부터 시작하는 것이 더 좋다. 인간은 습관을 가진 동물이어서 초기부터 오버(과도한) 테스트(over-testing)라는 나쁜 습관을 가지게 되면 나중에 털어버리기 어렵다. 그리고 그것은 털어내야만 하는 것들이다.

"하지만, 과도한 테스트가 정말 해로운 것일까? 필, 당신은 코드를 안전하게 유지하고 싶지 않아? 만약 프로덕션 환경으로 들어갈 때 단 하나라도 버그를 발견한다면, 그것은 가치가 없는거야?" 젠장 가치가 없는 건 아니잖아. 필 거기에 나를 불러들이지 마! 여기에서 논의하고자 하는 것은 어떻게 우리가 TSA를 우리것으로 만드는 것인가이다.

테스트는 공짜가 아니다.

우리가 쓰고 있는 코드의 모든 행은 비용이다. 거기에는 작성 시간, 업데이트 할 시간, 그리고 읽는 시간, 이해하는 시간이 필요하다. 그래서 테스트로 인한 혜택은 테스트를 만드는 비용보다 커야한다. 그렇지 않으면, 그것은 과도한 테스트가 되어 버린다.

이렇게 생각해 보자. 버그 방지를 위한 비용이란 무엇인가? 만약 1,000줄의 검증 테스트가 단 한 번만 밥이 사고로 validates_presence_of :name 선언을 지워 버린 것을 감지하면, 정말 가치가 있는 것일까? 물론, 아니다.(아, 알았다 알았다. 만약 네가 항공 관제탑에서 화성을 향해 로켓을 발사하기 위해 일을 하고 있고, 만약 name으로 스케쥴되어 있지 않은 경우 로켓이 백악관에 충돌해 버린다면, 테스트해야 한다 -하지만, 그정도가 아니면 잊어라.)

과도한 테스트라고 불리우는 문제는 캐치 프라이즈(익숙한 문구)로 귀결시키는 것은 어려운 문제다. 테스트 주도 개발을 무대의 중심축으로 추진하는 것을 도와주는 테스트 우선이나, red-green, 다른 섹시한 말처럼 간결한 것은 없다. 꼭 좋은 유용한 테스트는 뉘앙스(미묘한 차이), 경험, 그리고 꼼꼼한 체험적 방법을 따른 것이니깐.

하지 말아야할 7가지 테스트

하지만 충분히 이해한 참가자에게 저녁 식사 2시간의 대화의 미묘한 차이를 블로그에 게시할 수 있는 사람은 많지 않다. 그래서, 전형적인 Rails 애플리케이션 테스트에는 영향이 적지만, 다음의 의견 목록에서 토론과 논쟁을 유발해 본다.
  • 커버리지 100%를 목표로 하지마라.
  • 제품과 테스트 코드의 비율이 1:2를 초과하면 냄새 나는 코드이고, 1:3이라면 악취가 나는 코드라고 생각하자.
  • 만약 당신이 전체 작업 시간의 3분의 1이상을 테스트에 투입했다면, 그것은 아마도 잘못한 것일수 있다. 그리고 절반 이상이라면 분명히 잘못되었다고 단정지을 수 있다.
  • ActiveRecord 표준 associations, validations, scopes는 테스트하지 마라. 내부적으로 테스트 기능이 있으니.
  • 별도의 요소를 통합할 때는 이슈를 위해서라도 통합 테스트는 할 수 있다.(단위 테스트를 할 수 있다면 테스트 통합 테스트는 하지 마라.)
  • 비 프로그래머들도 테스트를 모두 작성해야 하는 마법의 나라에 살고 있지 않다면, Cucumber를 사용하지 말아라.(만약 정말 거기에서 살고 있다면, 언쟁할 요정을 보내달라고 해라.)
  • 컨트롤러, 모델, 뷰에 대해 항상 테스트 우선주의를 강요하지 마라.(나의 경우는 20%가 선 테스트, 80%가 후 테스트이다.)
우리는 수백권의 책에서 어떻게 테스트 주도 개발을 시작할지 여부만 알았지, 짐승을 어떻게 길들이지에 관해서는 1, 2가지 방법에 집중하기만을 바란다(몇가지 요령만 기억한다는 의미). 테스트의 방법에 관해 모두가 같은 볼링과 베이컨의 예에 집중하고 있을 때 손실되는 유용한 테스트가 무엇인지를 이해하는 것은 아주 어려운 일이다.

그러나 중요한 것은 먼저 해 두자. TSA 스타일 테스트 즉, 현장 품질 커버리지는 우리가 앞서 가기 전에는 신뢰할 수 없는 것이라고 단체로 결정해야 한다. 모두를 테스트해야만 할 정도로 아주 중요한 수준의 응용 프로그램은 거의 없다. 주장의 타당성을 올리기 위해서 테스트 주도 개발 전문가로 유명한 Kent Beck의 말을 빌리자면,

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it.

나는 코드가 작동하는지에 대해 보수를 받지, 테스트를 위해서는 보수를 받지는 않는다. 그래서 나의 철학은 신뢰할 수 있는 수준에 도달하기 위해 가능한 한 테스트를 적게 한다는 것이다.(신뢰할 수 있는 수준이라는 것은 업계 표준에 비해 높다. 조금 거만한 들릴지 모르지만). 만약 전형적인 실수(생성자에서 다른 변수를 설정하는 것 같은)를 하지 않는다면, 나는 테스트하지 않는다.
Tags : ,


Re: TDD에 관한 비용적인 관점

"TDD is an awareness of the gap between decision and feedback during programming, and techniques to control that gap" 이 내용도 참 와 닿습니다.


Add a comment Send a TrackBack