[공유] TDD is dead. Long live testing.
Byeongweon Moon
Youngrok Pak
--
이 메일은 Google 그룹스 'xper' 그룹에 가입한 분들에게 전송되는 메시지입니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 xper+uns...@googlegroups.com에 이메일을 보내세요.
더 많은 옵션을 보려면 https://groups.google.com/d/optout을(를) 방문하세요.
Byeongweon Moon
June Kim (김창준)
루비 이야기가 나오길래 관련이 있는 사람인가 했었는데, 과연 그러했군요. 알려주셔서 감사합니다. :-)국내에 TDD 도입이 미미한 상황이기 때문에 말씀하신 것과 같이 이에 해당하는 케이스가 많지는 않을 것 같습니다. 다만,도입하는 조직의 측면에서 보자면 그 주변에는 비슷한 사람들이 모이는 경우가 있으니 그런 일종의 작은 커뮤니티에서는 참고할 부분도 있지 않을까 생각됩니다.제 개인적인 의견을 이야기 하자면, Test-First라는 관점은 일종의 취향이라고 생각하기 때문에 어떻게 하든 무방하다는 주의입니다. 다만 자동화된 테스트(유닛이든 회귀든)는 필요하고 이는 특히 유지보수의 관점에서는 필수라고 생각하는 쪽입니다. 따라서 글쓴이의 의견이 어느 정도 일리가 있다고 생각해서 이야기를 해보고자 공유한 것이죠.
그리고 말씀하신 국내에서 하기엔 아직 사치스러운 걱정이라는 부분에는 저도 동감합니다. 다만, 이러한 걱정을 하는 글들에서 본인이나 주변의 경우에서 앞으로 겪게될 문제나 현재의 문제를 미리 파악해서 대처할 수 있다면 좋겠지요. 일단 제 경우에는 앞서 이야기 한 것과 같이 TDD등에 대한 반감을 가진 분들 중 일부를 이해할 수 있는 단서를 얻을 수 있었습니다. 이를 활용해서 대처해 나가면 좋겠죠.
Park, Sungchul
https://twitter.com/WardCunningham/status/460281553017249794
저는 TDD와 함께 xUnit까지 죽을까봐 걱정입니다. 많은 사람이 TDD와 xUnit을 구분하지 않고 사용하기도 하고, xUnit을 못하는 이유로 TDD의 비현실성(?)을 내세우니까요.
4/24/14, 1:26 PM, Youngrok Pak 쓴 글:
글쓴이는 Ruby on Rails의 개발자죠. 흔히 DHH라고 줄여서 부르곤 하는데, 유명한 사람입니다. DHH는 예전부터 Test first에 대한 반감을 많이 표출했고, test를 regression test 관점에서만 생각해왔던 걸로 알고 있습니다.
어떤 기술이나 방법에 대해 moral의 관점에서 접근하는 것은 저도 좋지 않다고 생각합니다. regression test만 하고 있는 사람에게 가서
"야, 그건 진짜 TDD가 아냐, test를 먼저 짜야지"
이런 식으로 말한다면 DHH처럼 거부감을 느낄 수 있겠죠. 하지만, 이걸 그냥 기술적인 문제라 보고,
"test를 그렇게만 하는 것보다 test first를 하면 여러 가지 이득이 많이 있어. 게다가 test first를 하지 않고 automated test를 짠다면 여러 가지 부작용도 있다구"
와 같은 식으로 접근해서 논쟁하는 것은 유익하다고 봅니다. 개발자가 기술적인 논쟁을 거부한다면 그건 거부하는 쪽이 더 문제겠죠.
사실 저도 이미 TDD는 죽었다고 생각합니다. 하지만 그게 TDD가 나쁘거나 적용하기 어려워서라기보다, TDD보다 xUnit이 더 가르치기 쉽고 배우기 쉽고 마케팅하기 쉽기 때문이라고 봅니다. 애자일 방법론 중에서 가장 애자일과 거리가 먼 스크럼이, 그것도 가장 딱딱한 형태로 확산되어서 애자일의 대표격으로 알려지는 현상과 비슷하죠.
test에 관한 이야기 중에 test를 나중에 만들더라도 없는 것보다 나으니 그래도 만들어라 이런 논리를 흔하게 접합니다만, 사실 전 이 논리에 의문을 갖고 있습니다. 제가 이래저래 떠돌이 생활을 많이 하다보니 여러 회사를 경험하게 되는데, regression test를 중시하는 조직일수록 개발 속도가 느릴 뿐 아니라 장애율마저 높은 경향이 보입니다. 물론 통계적인 데이터는 아닙니다만, 그런 팀의 일하는 방식을 관찰해보면 어느 정도 이유들이 보입니다.
그리고, 교조적으로 강요하는 건 제 경험상으로는 regression test만 하는 팀이 더 심했던 것 같습니다. 기능을 하나 개발하면 반드시 테스트를 붙여야 한다 같은 룰이 있는 경우가 많았죠. 반대로 TDD를 하는 팀은 테스트 커버리지를 중시하지 않았고, 모든 기능을 TDD로 만들지도 않더군요. 필요할 때만 test를 작성한다는 거였고, TDD를 오래 했던 고수일수록 작성하는 테스트의 숫자가 적은데도 더 잘 동작하는 코드를 만들었습니다.
TDD가 좋으냐, test first 필요 없고 regression test가 중요하냐 이런 건 앞으로도 계속 치열하게 논쟁해 나가야 할 문제라고 생각합니다. 저 역시도 팀에서 그런 논쟁을 여러 번 했었구요. 그런 논쟁이 서로 동등한 관계에서 이루어지기만 하면 문제 없겠죠. 네 말도 옳고 네 말도 옳고 황희정승 놀이 하는 것 보다야 서로 치열하게 공격하고 반격하는 것이 개발자 커뮤니티에 유익한 일인 듯.
그리고, 애자일이든 TDD든 그걸 교조적으로 따라야 한다고 주장하거나, 그걸 아는 사람 모르는 사람으로 나누는 기준이 된다거나 할 정도로 국내에 많이 퍼져 있는지도 의문입니다. TDD에 관해서는 김창준님이 번역하신 테스트 주도 개발처럼 좋은 교재가 있음에도 불구하고 테스트 많이 한다는 팀 중에 이 책을 정독한 사람은 정말 찾기 어려웠습니다. 애자일 한다는 회사에도 애자일 선언 제대로 읽어본 사람이 드물었구요. 애자일이건 TDD건 교조적으로 따르고 있는 사람 자체가 드문데 그 얼마 안되는 사람들이 강요까지 하고 다닐까요?
DHH가 처한 상황은 어떤지 잘 모르지만, 국내에선 하기는 아직 사치스러운 걱정인 것 같습니다.
안녕하세요? 문병원입니다.--
어쩌다보니 Xper 그룹에 외부의 글들을 주로 공유하게 되는데요,
여러 글을 읽다가 이곳의 분들과 나누고 싶은 것들을 보면 공유하고 싶은 마음이 들어서 그런 것이니 혹시나 불편하신 분들이 계시다면 양해 부탁 드립니다.
링크만 걸면 원문이 영어라 접근이 불편하실 분들도 있을 것 같아서 앞으로는 간단한 제 생각이나 요약이라도 정리해보도록 하겠습니다.
제목은 "TDD는 죽었다. 테스팅이여 영원하라." 정도로 변역이 가능하겠는데요.
전 이사람이 누군지는 모릅니다. 업계에서 명성이 있는지 없는지도 모르겠네요. 다만, TDD에 대한 이야기를 하고 있고, 생각해볼 만한 부분이 있다고 보여서 공유를 하는데요.
글의 내용은"TDD의 테스트 우선이라는 아이디어가 너무 교조적이 되고, 프로그래머를 나누는 기준이 되는 등의 원래의 의도가 사라지는 상황에서 자신은 TDD를 통해 테스트의 중요성을 알게 되었기 때문에 자동화된 테스트에는 동의하지만 TDD에 대한 의무에는 반대한다."정도입니다. 제 요약이기 때문에 글을 읽는 분들마다 다른 요약이 나올 수는 있으니 한번 읽어 보시길 권합니다.
글의 내용중 읽어볼 만한 문장이라 생각된 부분을 가져와봤습니다. 주변에도 보면 TDD 등에 대한 반감을 가지고 있는 분 중에 자신이 그러한 것들을 모르는 것에 대해서 낮게 평가하는 것에 대한 반발이 반감이 된 경우를 보았는데, 아래 글에 그러한 맥락이 있습니다.
그러한 맥락에서 보면, 혹시나 일종의 새로운 혹은 진보된 형태의 기술을 사용하는 집단에서 그렇지 않은 집단에 대한 심리적인 무시나 폄훼등이 존재하는 경우도 생각해 볼 수 있을 것 같습니다. 우선 제 경우부터 그런적은 없는지 반성을 해보게 되네요.
Maybe it was necessary to use test-first as the counterintuitive ram for breaking down the industry's sorry lack of automated, regression testing. Maybe it was a parable that just wasn't intended to be a literal description of the day-to-day workings of software writing. But whatever it started out as, it was soon since corrupted. Used as a hammer to beat down the nonbelievers, declare them unprofessional and unfit for writing software. A litmus test.
이 메일은 Google 그룹스 'xper' 그룹에 가입한 분들에게 전송되는 메시지입니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 xper+uns...@googlegroups.com에 이메일을 보내세요.
더 많은 옵션을 보려면 https://groups.google.com/d/optout을 (를) 방문하세요.
종소리
요즘은 게다가 SOA가 되면서 이젠 서비스끼리 메시지도 큐로주고 받는데, 어떨땐 이렇게까지 할필요가 있나 싶습니다. 물론 코드의 파퍈화, 양파껍질화가 꼭 TDD의 잘못이라곤 할수 없지만 그동안 TDD의 전도자들이 이런 설계를 교리처럼 밀어붙인 경향이 있지 않나 싶네요.
June Kim (김창준)
--
박상규
Jisung, Ahn
박상규
앨리카
2014년 5월 7일 수요일 오전 5시 34분 30초 UTC+9, 김창준 님의 말:
김해기
TDD가 (특히 test driven design의 측면에서) 쓸모 있냐 없냐, 혹은, TDD가 개발자에게 must(prerequisite) item(^^)으로 합당한가 아닌가에 대한 논란(!)처럼 받아들여질 수 있겠어요.
(Martin Fowler가 말하길) 이번 Hangout 시리즈가 논쟁을 위함이 아니라 다른 주장을 이해하고 TDD의 여러 측면을 배우기 위함이라고 하는데, 옳고 그름을 가려주세요~ 하는 기대감을 갖는 분들이 많은 모양입니다. [ Many people speak of looking forward to a “death match” fight between us. (중략) but we are more interested in exploring these topics in a way that expands our understanding of each others’ ideas. ]
Hangout을 제안한 Kent Beck에 존경심이 일어납니다.
DHH가 [ Used as a hammer to beat down the nonbelievers, declare them unprofessional and unfit for writing software. ]라고 했는데 TDD가 그런 게 아니라, TDD하는 일부 (아님, 많은) 사람들이 그렇게 한 거죠. (TDD를 널리 알려 쓰이게 하고자 하는 열정/조급함과, 그렇게 하지 않는 개발자들에 대한 답답함에)
논쟁의 시발을 (뜻하지 않게) 제공한 David Heinemeier Hansson 조차도 TDD와 관련한 논쟁을 의도한 것으로는 보이지 않습니다. Rails conference 2014에서 한 keynote(http://www.youtube.com/watch?v=9LfmrkyP81M)의 핵심은 Developing an eye와 Software writer(not engineer)라는 말에 있다고 봅니다. TDD와 관련해서는, Rails를 개발하면서 Test first를 따랐더니 결과적으로는 설계와 품질에 그다지 도움이 되지 않더라는 경험에 따라, 이러저러한 practice를 (맹목적으로) 따르는 것 보다는 좋은 코드를 짜기 위한 의식적인 노력과 연습이 더 중요하더라는 얘기를 하고 싶었던 것으로 보입니다.
왜 Ruby에서는 TDD(엄밀히 말하면 xUnit test framework)가 그닥 도움이 되지 못했을까 궁금해서 Ruby를 잠깐 봤는데, (그러니 짦은 의견입니다만) block(function)들이 inline되어 쓰이는 자유가 유용하게 제공되기에, OOP에서 유용한 TDD가 Ruby에서는 적합하지 않았을 수 있겠다 싶었습니다. (이와 관련해서는 Ruby 개발자 분들의 의견과 경험이 덧붙여지면 좋겠어요) Context is everything.
그리고, mocking을 heavy하게 사용하게 될 때의 문제 또한 겪은 듯 합니다. Class의 파편화를 야기하게 되겠지요. 이와 관련해서 Robert Martin이 Hangout 즈음에 When to Mock(http://blog.8thlight.com/uncle-bob/2014/05/10/WhenToMock.html)을 썼습니다. Martin Fowler나 Kent Beck이나 mocking을 그다지 쓰지 않는 것으로 알고 있구요. Unit testing에서 unit의 의미를 class와 동일하게 취급하는 경향이 있는데, 이는 잘못된 개념 정의라고 합니다. 관련하여 Martin Fowler가 UnitTest(http://martinfowler.com/bliki/UnitTest.html)를 썼는데, 이도 최근의 글이군요.
이번 대화/논쟁의 결론을 조심스럽게 점쳐 보자면, DHH 자신이 keynote에서 인용했듯이 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. ]가 될 것 같습니다. (또 한번 Kent Beck에 대한 존경심이... ^^) Test coverage 따위가 아닌 "confidence"를 얘기하고 있는 점이 상당히 신선한 충격입니다.
상대적으로 어린 나이에 그만한 인식과 경험을 가진 DHH도 대단하고, 포용할 줄 아는 Kent Beck은 더 대단하다는 생각이 듭니다.
TDD를 해야 한다, 할 필요가 없다,는 식의 결론은 Kent Beck도 DHH도, 그 어느 누구도 말하고자 하는 핵심이 아니라고 봅니다. 우리가 받아들이고 배워야 할 것은 TDD(뿐만 아니라 그 어느 practice 또는 변화이건 간에)의 여러 측면을 이해하고자 하는 여러 대가 분들의 태도와 마음가짐인 것 같습니다.
DHH가 keynote에서, 무조건적인 practice/tool의 예로 design pattern과 TDD를 들면서 꽤나 격하고 선정적인(?) 용어들을 썼는데, 그건 DHH가 아직은 어리고 패기에 넘쳐 있으며 keynote에 좀 더 재미와 자극으로 양념을 치고자 한 게 아닌가 넘겨짚어 봅니다.
Robert Martin도 TDD를 context와 상관없이 모든 프로 개발자의 '척도'로 보고 있지는 않으리라 생각합니다. OO 패러다임 상에서의 (하긴, 객체지향이 대세이긴 하니까) 개발자가 갖춰야 할 필수 덕목 정도가 될 것이라는 전망이지, 얼마나 프로페셔널 하냐의 바로미터로 여기고 있다고 보이진 않았어요.
TDD의 pros 쪽은 TDD의 가치를 더욱 찾고 알리려고 할 테고, TDD의 cons 쪽은 TDD만이 유일한 practice가 아니고 많은 경우에 cost를 높이는 문제를 야기할 수 있다는 (거부감 섞인) 얘기를 하고자 할 테니, 그 연장 선상에서 이번 논쟁을 보는 것이 어떨까 싶어요. 양쪽 모두 (교조적인 태도만 아니라면) TDD의 발전에 기여할 것입니다. 그래서 Kent Beck에 박수!
당연히, TDD 한다고 설계가 자동으로 좋아지지는 않겠죠. TDD를 했을 때 얻게 될 수(도) 있는 보너스?! ^^
Dirty 코드를 짜는 사람은 어떻게 해도 dirty 코드를 짤 것이고, clean (DHH 왈, clear & readable) 코드를 짜려는 사람은 뭐 없어도 clean code, simple design을 짜려 애쓸 것입니다. 저 같은 많은 평범한 개발자들이 TDD를 통해 dirty code에 대한 인식을 하고 clean code를 향한 방향을 잡을 수 있지는 않나 싶습니다만, 이 또한 누구는 production code를 향한 나침반 또는 청진기로 여기는 반면, 또 다른 누구는 TDD를 프로그래밍 유토피아를 꿈꾸는 어느 세상물정 모르는 아이의 장난감으로 여길 것이니까요. (교조적 발언인가? ^^) Robert Martin도 얘기했듯이, TDD 안 한 많은 대가들도 여전히 대가들입니다. TDD를 통해 얻을 수 있는 이득을, 다른 방식과 도구와 노력으로 경험하고 쌓아온 software writer++들이지요. (지금은 TDD 재발견 이후의 세상이니 TDD를 제대로 해보는 것이 성장에 도움이 되지 않을까요? DHH도 (뭐 좀 다른 context에서) 해 봤는데.)
DHH가, 소프트웨어 개발자가 스스로를 engineer로 볼 것이 아니라 writer로 여겨야 한다는 대목이나, developing an eye를 위해서 (코드를) 많이 읽고 많이 작성하라고 조언한 것은 Gerald Weinberg를 비롯한 많은 대가들이 던지는 조언과 일맥상통해 한 번 더 되새기게 됩니다.
Hangout을 통해 대가들을 만날 수 있으니 기대와 기쁨~~~~
근데, 모든 글 잘 쓰는 작가(writer)가 독자들(readers, users, other developers)에게 감흥이나 유용함을 주는 것은 아니니, 글 잘 쓰는(writer) 것 말고도 무엇(writer++)이 더 필요합니다. 뭘까요???
2014년 4월 24일 목요일 오후 12시 22분 59초 UTC+9, Byeongweon Moon 님의 말: