2014년에 DHH는 ‘TDD is dead. Long live testing.’이라는, 제목이 아니라 내용이, 다소 황당한 글을 썼고 얼마 후 Kent Beck은 관련된 글을 썼다.

RIP TDD

DHH가 TDD를 죽여서 TDD를 대신할 방법을 찾아야 한다는 글인데, 제대로 읽었다면 누구도 이것이 Kent Beck이 TDD를 떠난다고 말하는 글이라고는 생각하지 않을 것이다. 내 가설의 증거는 댓글들이다. 재미있으니 댓글들도 한 번 읽어보기를 추천한다.

그럼 실제 내용은 뭘까? 프로그래머가 TDD를 통해 얻을 수 있는 가치의 나열이 대부분이고 나머지 조금은 DHH에 대한 조롱이다. 나는 여기에 나열된 TDD의 효과 모두를 느껴왔고 그래서 TDD를 사용한다. 그리고 이 가치들이 더욱 알려지기를 바라는 마음에 한국어로 번역했다. 내 영어 실력은 아주 형편 없어서, 노력했지만 두 구절은 충분히 이해하지 못해 직역했다. 표시해 뒀으니 좋은 해석 의견이 있다면 대환영이다. 이후로는 모두 내 글이 아니라 번역이다.

DHH는 TDD를 역사의 단편으로 보내버렸습니다. 나는 슬픕니다. 내가 처음부터 역사의 단편에서 TDD를 구해 냈기 때문이 아니라, 프로그래밍 할 때 많은 문제를 해결할 수 있는 새로운 기법을 찾아야 하기 때문입니다.

  • 오버 엔지니어링. 나는 내가 “필요하게 될” 거라고 “알고 있는” 기능을 추가하려는 성향이 있습니다. 하나의 빨간(실패한) 테스트를 녹색으로(성공하도록) 만드는 것은 딱 충분한 만큼만 구현하도록 도와줍니다. 나는 집중을 유지할 새로운 방법을 찾아야 합니다.
  • API 피드백. 내 API 결정에 대한 빠른 피드백을 얻으려면 새로운 방법을 찾아야 합니다.
  • 논리 오류. 내가 만들어내는 성가신 *테스트 감각 오류를 잡아낼 새로운 방법을 찾아야 합니다.
  • 문서화. 내가 어떻게 API가 사용되기를 기대하는지 전달하고 개발 중에 생각했던 것을 기록하는 새로운 방법을 찾아야 합니다.
  • **막막함. TDD를 사용해, 설사 구현을 상상할 수 없더라도 거의 언제나 테스트 작성법을 알아낼 수 있었던 방식을 그리워 할 것입니다. 나는 산을 한 걸음 더 오를 새로운 방법을 찾아야 합니다.
  • 구현 사고와 인터페이스의 분리. 나는 구현의 추측으로 API 디자인 결정을 오염시키는 성향이 있습니다. 두 사고 수준을 분리하는 동시에 그것들 사이의 피드백을 신속하게 제공할 새로운 방법을 찾아야 합니다.
  • 합의. 나는 프로그래밍 파트너와 내가 푸는 문제에 대해 명확해 질 수 있는 새로운 해결책을 찾아야 합니다.
  • 걱정. 아마도 내가 가장 그리워 할 대상은 TDD가 즉각적인 “다 괜찮지?” 버튼을 제공한다는 것입니다.

나는 이 모든 문제를 해결할 다른 방법을 찾을 수 있을 것이라 확신합니다. 때가 오면. 고통이 사라질 것입니다. 잘 가 오랜 친구 TDD.

* sense-of-test
** Feeling overwhelmed