• Test-first fundamentalism(테스트 우선 근본주의)는 마치 금욕을 하라고만 하는 성교육과 같다.
    • 자기 혐오에 빠져있는 사람을 위한 비현실적이고 실효성없는 도덕교육 같은 것이다.
  • 처음부터 이렇게 생각한건 아니다.
    • 내가 처음 TDD를 발견했을때는, 더 나은 소프트웨어 개발의 세계에 정중하게 초대받은 느낌이었다.
    • 테스팅이 없던 세계에서 테스팅의 세계로 이끌렸다.
    • 잘 테스트된 코드 베이스의 평안함에 눈을 뜨게 해줬다.
      • 소프트웨어를 변경할 때의 확신, 신뢰에서 오는 기쁨을 알게 되었다.
  • “테스트 우선”은 테스팅을 깊은 수준으로 사고하는 방법을 가르쳐주는, “자전거의 보조바퀴”와 같은 훌륭한 도구였다.
    • 나는 그것을 통해서 테스팅을 깊이 배웠고, 곧바로 보조바퀴 없이 자전거를 탈 수 있게 되었다.
  • 몇년 세월이 흘렀지만 “테스트 우선”이라는 레토릭은 좀더 목소리가 커졌고, 좀더 격렬해졌고, 좀더 Mean-spirited(비열한, 옹졸한) 해졌다.
    • 나도 근본주의에 들어가서 진정한 교리(true gospel)를 따르지 않는 것은 나쁜 일이라고 느낄 수도 있었다.
    • 그래서 “테스트 우선”을 몇 주 해봤지만, 내 디자인을 나쁘게 만들어서 관뒀다.
  • 테스트 우선의 가르침을 지킬 수 있을때와 지킬 수 없을때의 절망감으로 내 자신감은 왔다 갔다 했다.
    • 교리를 지키지 않으면 난 열차에서 내려진 기분이었다.
    • 이것에 대해선 침묵하고 있어야 했다.
    • 공개적으로 얘기해선 안 된다.
    • 공개적으로는, 난 테스트 우선을 항상 하고 있는 것은 아니라고 넌지시 얘기하는게 내가 할 수 있는 최선이었다.
      • 최악은, 테스트 우선을 “올바른 방법”이라고 지지까지 해오고 있었다.
    • 지금은 후회하고 있다.
  • 아마 처음엔 “테스트 우선”을 사용해서 자동화된 회귀 테스팅이 존재하지 않는다는 업계의 믿음을 깰 필요가 있었을지 모른다.
    • 어쩌면 처음엔 소프트웨어를 매일 만드는 작업에 그대로 사용할 생각이 아닌, 단지 비유적인 표현이었을지도 모른다.
    • 하지만 그게 어떻게 시작되었든, 지금은 타락했다.
    • 불신자들을 때리는 망치로 사용되고, 소프트웨어를 개발하는데 적합하지 않은 비전문가를 규정했다.
    • 리트머스 시험지가 되었다.
  • 충분하다.
    • 이제 관두자.
    • 내 이름은 David.
    • 난 테스트를 먼저 개발하지 않는다.
    • 난 이것에 대해 사과할 생각이 없고, 숨기지 않겠다.
    • 자동화된 회귀테스팅에 눈을 뜨게 해준 TDD에 감사하지만, 디자인의 교리로는 사용하지 않게 되었다.
  • 테스트 우선 접근이 당신의 시스템 설계의 무결성과 일관성에 어떤 영향을 주고 있을지 엄격히 검토하기 바란다.
    • 만약 좋은 것이 아닐 가능성이 있다는 것을 진지하게 고민해 본다면, 당신은 빨간약을 먹게 될지도 모른다.
    • 그 후에 보이는 것이 마음에 안 들지도 모른다.

그래서 우리는 어디로 가야 하나?

  • 첫 단계로, 문제가 있다는 것은 인정하자.
    • 두번째 단계는, unit 부터 system 사이의 테스팅 스펙트럼의 균형을 잡는 것이다.
    • 현재의 광신적인 TDD 운동은 unit 테스트를 포커스하는 경향이 있다.
      • 왜냐하면 코드의 디자인을 driving 하는 것이 unit 테스트이기 때문이다.
      • (이것이 테스트 우선의 명분이다.)
  • 좋은 생각으로 보이지 않는다.
    • 테스트 우선 방식의 unit 테스트는 중계(intermediary) 객체들이 얽혀있는 과도하게 복잡한 구조를 만들기 쉽다.
    • 또한 “느린” 것은 모두 피하기 위해서, 데이터베이스 및 파일IO 같은 것들은 피한다.
    • 브라우저를 사용해서 시스템 전체를 테스트 하는 것도 피하려고 한다.
    • 결국, 정말 무섭고 거대한 구조가 만들어 진다.
    • 서비스 객체와 커맨드 패턴, 그리고 더 나쁜것들이 얽힌 정글이다.
  • 모든 의존 관계를 mock 객체로 만들고, 수천개의 테스트가 몇 초 안에 끝나는 등의 전통적인 의미에서의 unit 테스트는 나는 거의 하지 않는다.
    • 그건 Rails 앱을 테스트하는데 좋은 방법이 아니다.
    • 나는 액티브 레코드 모델을 직접적으로 테스트 한다. 데이터베이스에 접근하도록 하고, fixtures를 사용해 테스트 한다.
    • 탑 레이어에는 컨트롤러 테스트가 있지만, 난 Capybara 같은 도구를 사용해서 높은 수준의 시스템 테스트로 대체하는 것을 선호한다.
  • 이것이 우리가 가야할 방향이라고 난 생각한다.
    • unit 테스트의 중요도를 낮춘다.
    • 왜냐하면 더이상 디자인 Practice로 테스트 우선 방식을 수행하지 않기 때문이다.
    • 그리고 system 테스트의 우선순위를 높인다. (맞다 느린 테스트 말이다.)
      • (하지만 병렬로 클라우드 위에서 실행되는 인프라 덕에 예전처럼 그렇게 느리진 않다.)
  • Rails는 이러한 전환에 도움을 줄 수 있다.
    • 오늘 우리는 전체 system 테스트를 장려하기 위해 아무것도 하지 않았다. Today we do nothing to encourage full system tests.
    • stack에는 정답이 없다. There’s no default answer in the stack.
    • 우리는 실수를 조금씩 고쳐나갈 것이다.
    • 하지만 당신은 그걸 기다리고 있지 않아도 된다.
    • Capybara에 들어오면 우리가 어떤 방향으로 가고 있는지 알 수 있을 것이다.
  • 심호흡을 한 번 하자.
    • 우리가 지금 하고있는 것은 성스러운 소를 죽이는 일이다.
    • 고통스럽고 피도 많이 나온다.
    • TDD는 크게 성공해왔다.
    • 이제 TDD는 단순한 기술이 아니라 그들 자신이 되었다.
    • 커뮤니티를 deprogramming 하려면 시간이 필요하다.
  • 최악의 방법은, 또다른 테스팅 종교를 전파하는 것이다.
    • “system 테스트가 전부야!” 와 같은 방식 말이다.
    • 제발 그렇게 되지 않았으면 한다.
  • 이렇게 나에게 “테스트 우선”은 죽었다.
    • 하지만 무덤 위에서 춤을 추는게 아니라, 공헌을 기리고 싶다.
    • 우리 역사의 중요한 부분을 새겼다.
    • 이제 다음으로 넘어갈 시점이다.

Long live testing. (“영원하라 테스팅” 또는 “테스팅 만세”)

내 감상

  • 만약 제목이 “unit 테스트 보다 system 테스트의 우선순위를 높이자” 였다면 이 글은 아무도 안 읽었을 것이다.
  • 예전에 DHH의 “스타트업이 돈을 버는 방법” 이라는 컨퍼런스 영상을 본 일이 있는데.
  • DHH는 참 마케팅을 잘 한다.
  • 그것이 Ruby On Rails가 한 때 매우 성공했던 이유이기도 하고.