Medium - Test Driven Development Is Dumb. Fight Me.
in Trend
Trend 파악을 Medium 기고문 요약 포스팅 - TDD는 멍청합니다; 논쟁을 시작해봅시다; 끔찍한 구현 뒤에 숨겨진 멋진 생각
그래요 저는 TDD가 솔직히 좋지 않다고 생각합니다. 게다가 날씬한 인플루언서가 그들의 군살을 교묘히 편집하는 것처럼 신입 개발자에게는 현실적이지 않은 목표입니다. 그래서 제 혀를 볼에 문지르며 존재하지 않는 함수에 대한 테스트를 작성하는 것이 얼마나 미친 짓인지 떠들어 보겠습니다.
pictured: me wasting time with opinions on the internet
Why do I feel this way?
즉 제가 이런 포스트를 이번 주에 쓰게 된 계기는 관련 경험이 있는 시니어 개발자와 얘기를 했기 때문입니다. TDD를 싫어하는 사람이 아니라 좋아하는 사람들 말이죠. 제가 TDD를 사용하는 것에 대해 묻자 많은 장점들이 쏟아져 나왔습니다. 그래서 제가 “그러니까 TDD를 업무에 사용하시나요?” 라고 묻자..
“Oh uh, well, the thing about TDD is …”
“시간이 부족해요,” “우리 개발문화는 그런게 아닙니다,” “제 페어가 원치 않아요.” “저와 제 여자친구는 항상 TTD를 합니다. 당신은 그냥 그녀를 모를 뿐이에요 그녀는 다른 학교에 가거든요”(??), TDD는 매우 좋지만 확실히 많은 사람들이 사용하고 있지는 않았습니다. 특히나 bootcamp에 있을 때 실망감이 컸는데 TDD를 사용하는 선생님은 아무도 없었지만 항상 그분들은 TDD를 꼭 사용해야 한다고 교육하셨죠. 많은 사람들과 TDD를 얘기할 수록 더 복잡했습니다, 왜냐하면 솔직히 왜 반대로 일을 진행하는게 왜 더 나은지 이해가 되지 않았거든요.
What are the benefits of TDD anyway?
TDD를 지지하시는 분들도 TDD가 작업을 느리개 한다는 것을 인정하실 겁니다. 그러나 지지자 분들은 결과 코드가 깔끔하고 잘 정리되기 때문에 장기적인 관점에서 시간을 절약하는 것이라고 합니다. 그렇지만 저는 TDD가 시간이 걸리는 이유는 단순히… 비효율적이어서 라고 생각합니다. 이것은 기분좋게 제게 증명되었는데 어떤 날 누군가가 TDD를 시도했었던걸 봤기 때문이죠.
The Incident
저는 흥분되었습니다, 한 선배 개발자님이 어떻게 TDD가 수행되는지 보여준다고 하셨거든요. 우리는 시작할 첫 함수와 기능들에 대해 얘기하고 테스트를 설계하고 실패하는 것을 지켜봤습니다. 우리는 함수에서 시작을 했지만 10분이 지나고 나서 그들은 멈췄습니다. 이 결과는 우리가 함수를 만든 방식으로는 테스트가 실제로 결함을 잡아내지 못했다는 것이죠. 우리는 작업을 멈추고 기능을 정의했던 곳으로 돌아가 다시 작업을 하고 테스트를 해야 했습니다.
우리는 함수로 살펴봤고 우리가 어떻게 나머지 시스템과 상호작용하는지 이해하지 못하고 있다는 것을 깨달았습니다. 그래서 우리는 어떻게 반응하는지 확인하기 위해서 코드를 어지럽히기 시작했죠. 우리는 함수의 기능을 바꾸고 결과를 로그로 살펴보았습니다. 그렇게 하니까 더욱 보기 편하고 설정을 바꾸거나 다른 작은 수정을 바꾸는 것으로 빠르게 작업을 완료할 수 있었습니다. 시간이 걸리긴 했지만 결국 우리는 특정 기능이 어떻게 시스템과 상호작용하는지 이해하게 되었습니다. 그 이후에 깨달은 것은 1) 우리의 함수는 완전히 coded하다는 것이고 2) 테스트는 잘못되었다는 것입니다.
Why didn’t TDD work?
왜냐하면 SW 개발은 쉬운 직업이 아니기 때문입니다. 물론 토이앱들에 TDD를 사용하는 것은 꽤나 달콤하게 들리죠. 그러나 현업에서는 기능들이 훨씬 복잡합니다. 종종 작업 중간에 제품 수정을 요청받기도 하고 아니면 해당 기능이 동작할 수 없다는 것을 알게되죠. 아마 이해하는데 어려움이 있을테고 처음부터 다시 시작해야겠죠.
위의 상황들은 일반적입니다, 그러나 매번 멈출 때마다 테스트를 작성하는 것은 문제를 더 심각하게 만들 것입니다. 여러분이 코드를 빠르게 작성하기 위해서는 수동으로 QA테스트를 수행하고 난 다음에 해당 상황을 따라하는 자동화 코드를 작성하세요 적절한 테스트가 수행되면 여러분은 마음 편히 다음 기능을 구현하거나 무언가 잘못될 것을 걱정할 필요없이 리팩토링을 할 수 있을 것입니다. 테스트를 지도가 아닌 가드레일로 사용하면 여러분은 모든 것을 예측해야 할 필요 없이 테스트의 모든 장점을 얻게 될 것입니다.
But TDD does have some good ideas
TDD에 대해 좋아하는 점이 많습니다. 사실 문자그대로 모든 테스트는 대단합니다. TDD에 숨겨진 생각 당신이 앉아서 생각을 먼저 하기 때문에 테스트를 작성할 수 있다는 것입니다. 그건 좋아요! 저를 포함해서 너무 많은 개발자들이 그들의 코드가 해야할 일을 생각하지 않고 바로 코딩을 시작하니까요. 단순히 함수의 목표와 요구사항을 적어놓는 것 만으로 진짜 테스트를 작성할 필요 없이 TDD의 장점을 얻을 수 있을 것입니다.
In Conclusion…
제가 이런 얘기를 하는 것은 테스트가 정말 중요하기 때문입니다. 테스트 없이 앱을 만드는 것은 차선이 없는 고속도로를 달리는 것과 같습니다. 저는 단순히 TDD가 여러분이 고속도로를 포장하기 전에 페인트칠을 하는 것이라고 말하고 싶네요. 여러분이 동의하지 않을 수도 있고 여러분은 진짜 TDD를 사용하고 사랑할 수도 있죠. 그러나 여러분이 사용하길 원치않는 다면 그래도 괜찮다는 겁니다. 우리 스스로 솔직해 지자구요. 만약 특정 코딩스타일이 이론적으로는 훌륭하나 실용적이지 않다면 좋은 부분만 얻고 나머지는 던져버립시다. 제 요점은 코딩에는 여러가지 스타일이 있고 우리가 그 방법들 중 하나를 최고의 방법으로 여길 필요는 없다는 것입니다.
말하자면 Behavior Driven Development는 아주 매끄러우며 여러분이 그렇게 하지 않는다면 멍청하다는 것입니다.
농담입니다.
Summary
- TDD에서 말하는 테스트를 먼저 작성하는 것의 의미
- 정확하게 무엇을 만들고자 하는지 한번 더 생각해봐야 하는 것, 코딩 전에 한번 더 계획을 세우는 것 그 자체가 중요하지 실제로 테스트를 작성하는 것은 차치해도 되지 않을까? 하는 입장.
- 바로 코딩을 시작하는 습관은 버리도록 하자.
