TDD는 벌거벗은 임금님의 투명옷인가? (2) - TDD의 사망에 대한 검증

TDD는 벌거벗은 임금님의 투명옷인가?

• 1. TDD는 죽었다. 테스트여 영원하라!
• 2. TDD의 사망에 대한 검증
• 3. TDD는 UT가 아니다

이번 포스팅에서는 지나번 소개한 Rails의 개발자 DHH의  "TDD는 죽었다. 테스트여 영원하라!"에 뒤이어 펼쳐진 TDD에 대한 일련의 논쟁을 다뤄보도록 하겠다.

 DHH는 이후 "테스트를 위한 설계의 폐해Test-induced design damage"과 "데이터베이스 테스트는 느리다라는 편견Slow database test fallacy"라는 포스팅을 추가로 발표한다. 시간도 많고 영어에 자신이 있다면 위의 글들을 한번 읽어 보는것도 좋겠지만 요점정리 중심의 참고서 교육에 길들여진 분들을 위해 InfoQ관련 기사('TDD 사망'에 대한 검증Examining the 'TDD is Dead' Controversy) 내용을 소개한다. (필자의 견해는 - 이후 각주 형태로 추가하였다.)

원문 :  Examining the 'TDD is Dead' - InfoQ

DHH의 주장 요점정리

• 많은 개발자들이 TDD를 사용하지 않는 코드는 더티한 코드라고 생각하도록 몰아넣고 있다. - 사실상 DHH가 이 논쟁을 시작하도록 한 직접적인 원인이 아닌가 싶다. 누군가 DHH에게 "니 코드는 구려. 유닛 테스트가 없쟎아?" 이렇게 말한것이 아닐까?
• 유닛테스트 주도의 설계는 좋은 생각이 아니다. - TDD 근본주의자들은 제대로 된 설계는 테스트하기가 쉽다고 말한다. 필자는 이것을 부정하진 않는다. 하지만 '테스트하기 좋은 설계' = '좋은 설계'가 성립하는것은 아니다.
• TDD의 개념인 "테스트는 빨라야 한다"는 근시안적인 생각이다. - 아무래도 테스트의 속도는 개발자 환경에선 부담이 될 수밖에 없다. 다행이도 젠킨스와 같은 자동화CI 툴이 도입된 이후로는 이러한 부담이 많이 줄었다. 자동화 테스트를 돌릴 수 있는 환경만 만들어 놓는다면 개개인은 자신의 코드에 대한 풀테스트 결과는 CI서버 상에서 확인 가능하게 되며 개인레벨에서 코드 커밋 이전에 수행해야만 하는 테스트는 코드에 의해 새로 작성된 테스트 케이스의 결과 확인만으로 충분할 것이다.
• TDD에 대한 믿음은 시스템 테스트를 완전히 잋어버리도록 만든다. - DHH의 이러한 생각은 시스템 테스트나 시나리오 테스트를 자동화 하도록 권장하는 BDD의 영향을 받은듯 싶다. 실제로 Ruby에서는 BDD툴인 RSpec이 큰 인기를 누리고 있다.
• 유닛테스트에 포커싱을 하거나 유닛테스트만을 행하는것은 큰 규모의 시스템을 만드는데에 도움이 되지 않는다. - 큰 규모의 시스템을 만들기 위해서는 반드시 여러 레이어를 횡단하는 테스트의 도움이 필요하다.
• 100% 커버리지는 웃기는 이야기다 - 100% 커버리지 달성에 목매는 개발현장을 심심찮게 본다.  이런 현장에는 십중팔구 생각하기 싫어 하는 PM이 존재한다. 100% 커버리지는 품질에 대한 그 어떤 보장도 되어주질 않는다.
• 프로그래머는 소프트웨어가 과학이 되길 원한다. 하지만 소프트웨어는 과학이 아니다. 그것은 좀 더 문학 창작에 가깝다. - 얼마전에 해커와 화가를 읽으면서 공감했던 부분.
• 좋은 소프트웨어는 엔지니어링과는 다르다. 
• 그것은 마치 글쓰기와 같다.  명확하고 간결한 글이 난해한 글보다 낫다.
• 명확함은 좋은것이다. 따라서 테스트 커버리지나 테스트 스피드가 아니라 명확함이야 말로 추구하는 목표중 하나가 되어야 한다. 
• 좋은 개발자가 되는것은 좋은 작가가 되는것만큼 어렵다. - 아무리 그래도 좋은 작가가 되기 보다는 쉽지 않을까? 아무리 생각해 봐도 좋은 개발자의 수가 좋은 작가의 수보다는 많아 보인다.
• 글쓰기와 마찬가지로 좋은 프로그래머가 되기위한 가장 명확한 방법은 많은 소프트웨어를 만들어 보고, 또 좋은 소프트웨어의 코드를 읽어보는것이다. - 100%공감한다. 

커뮤니티에서 이에대한 반응은 광범위하게 나타났으며(트위터의 관련 해시태그#tddisdead를 보라), 반응또한 "역시 그렇군"에서 "멍청한 소리다"까지 다양하게 나타났다.

응답의 대부분은 TDD를 좀 더 실용적으로 적용할 필요가 있음에 초첨을 맞추고 있다.

스스로를 소프트웨어 장인집단으로 부르는 8thlight의 대표 Martin은 자신의 블로그에서 "만약 당신이 TDD를 하지 않으면서 TDD 만큼 효과적인 다른 무언가를 하려고 한다면, 기분이 나빠지게 될 것이다."라고 말한다. 그의 이야기를 좀 더 들어보자.

왜 우리는 TDD를 하는가? 우리는 TDD를 한가지 가장 중요한 이유와 다른 몇가지 덜 중요한 이유때문에 실시한다. 덜 중요한 이유들은 다음과 같다.

1. 디버깅에 쓰는 시간을 줄일 수 있다.
2. 테스트 자체가 정확하고 꼼꼼하며 명확한 가장 저레벨의 시스템 사양이 된다.
3. 테스트 우선 개발에 있어 각각의 테스트는  다른 테스트들과 디커플링 될 필요가 있다. 우리는 이러한 디커플링이 유익하다고 믿는다.

이러한 것들이 덜 중요한 TDD 도입의 필요성들이다. 그리고 이것들은 아직 논쟁의 여지가 있다. 그렇지만 가장 중요한 이유에 대해서는 논쟁의 여지가 없을것이다.

• 만약 당신이 실뢰할 수 있는 자동화 테스트를 가지고 있다면,  그리고 그 테스트가 언제든지 실행될 수 있다면 , 당신은 테스트가 모두 통과되었다는것 하나만 가지고도 아무런 두려움 없이 빠르고 간편하게 코드를 개선해 나갈 수 있다.

Martin Fowler “Hey. Soap. You wanna know this week’s Lotto numbers?”

Martin Fowler "My war ends with you."

Martin Fowler는 DHH와 Kent Beck을 초대하여 둘 사이의 논쟁을 중계하였다. (Kent Beck은 DHH의 포스팅에 대해 즉각적으로 반응했었다.)

리즈시절의 Kent Beck 사진.

2014년 7월 시점의 Kent Beck 페북 프로필 사진.
외모와는 달리 구글 플러스의 이벤트로 진행된  토론에서의 모습은 애교가 넘치신다.

Martin Fowler는 이번 토론에 대해서 다음과 같이 요약했다.

1)우리는 TDD의 흐름에 대해 우리들의 경험을 이야기 했는데, 방법론으로서의 TDD와 자동화 코드는 자주 혼동되어졌다.
2)DHH는 hexagonal rails와 같은 테스트 주도 개발의 접근방식에 의한 테스트 코드를 의식한 설계가 과도한 간섭과 복잡성으로 인해 망가질 수 있다고 생각한다. Kent는 그것이 TDD에 기인한 문제라기 보다는 설계 자체의 품질 문제라고 생각한다.
3)우리는 프로그래밍을 하는동안 피드백을 얻을 수 있는 당양한 체널을 통해 논의를 진행하고, 품질보증의 피드백을 개발자들에게 제공한다.
4)우리는 테스팅과 TDD의 몇몇 단점들에 대해서 논의했다. 당신은 너무 많은 테스팅을 하고 있는가? 그리고 그러한 테스팅은 기능 코드가 가져다 주는 가치보다 팀에게 더 많은 가치를 제공하는가? - 테스트 코드와 실행코드 사이의 밸런스에 대해서 생각해 보자.

Gergely Brautigam은 "TDD는 죽었다. - 사실이 아님TDD is Dead - Not really"라는 제목의 포스트에서 다음과 같이 말하고 있다.

TDD는 죽지 않았다.  명백하게 아직도 많은 사람들의 지지를 받고 있는데 어떻게 죽었다고 할 수 있는가?  이것은 마치 디자인 패턴은 죽었는가? 또는 Functional Automation이 죽었는가? 또는 오레오 쿠키는 죽었는가? 와도 같은 질문이다.
그렇다. TDD는 죽지 않았다. 그리고 지금까지 죽은적도 없다. 그것은 아마도 새로운것으로 변화 하거나 보다 나은것으로 바뀔 수는 있을것이다. 하지만 절대 죽지는 않는다. 그러므로 이 이야기는 이제 그만두자.

그는 다양한 레벨에서의 데트팅의 중요성과 일반적으로 테스트가 제대로 이뤄지지 않는 많은 팀들에 대한 이야기를 이어갔다. 그는 테스트 코드를 작성하지 않는 일반적인 이유로서 품질에 대한 관심부족과 시간에 쫓기는 많은 개발자들을 예로 들었다.
그의 결론은 다음과 같다.

그것은 소프트웨어 테스팅에 대한 10년간의 관찰과 경험속에서 얻은 저의 결론입니다. 시작은  가벼운 틀 위에서 진행하고, 몇가지 선행 테스트들은 당신이 이것을 오래 지속하는데 도움을 줄 것입니다. 적어도 한두개의 납입테스트는 당신의 비즈니스 로직을 더 잘 이해하는데 도움을 줄 것입니다. 한두개의 유닛테스트 역시 당신이 당신의 로직을 이해하는데 도움이 될껍니다. 나는 빌어먹을 모든 테스트를 전부 다 하라고 말하는게 아닙니다. 내가 아는 한 당신은 그럴 필요가 없습니다. 하지만,  품질을 위해서 최소한 몇개는 작성해야 합니다.

Gil Zilberfeld는 애자일 선언문으로부터 다음과 같은 포인트를 찾아내었다.

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 우리는 아직 완벽한 방법을 알아내지는 못했다.  TDD는 다른것들과 마찬가지로 보다 나은 소프트웨어 개발을 위한 여정에서 찾아낸 아이템들중 하나일 뿐이다.