소프트웨어 개발, 테스팅 또한 경제적인 활동이다. 자원(시간, 인력)을 적게 투입하여 최대한의 효용을 뽑아내어야 한다 코드에 따라 유닛 테스트는 필요할 때도 있고 필요하지 않을 때도 있다. 유닛 테스트가 필요한 경우는 다음과 같다 1) 알고리즘이 매우 복잡하지만 수학적으로 잘 정의된 경우, 구현 상의 명백한 버그를 없애기 위해 필요하다 2) 제품이 실제로 사용되고 발전하면서 자꾸 변하거나 가정이 틀리는 부분의 버그를 없애기 위해 필요하다 1에서는 TDD가 어느 정도 유용할 수 있으나 2에서는 쓸모가 없다. 코드의 어떤 부분이 변경될지 예측하는 것은 어렵기 때문이다. 1은 애초에 안 변하고, TDD 방식으로 모든 코드에 대해 테스트를 짤 경우, 특히 2에서 코드를 변경해야하는데 테스트가 발목을 잡는다. 그러므로 (포프는) 제품 코드 전에 테스트 코드를 짜자는 TDD 방식을 쓰지 않는다. 일단 코드를 그냥 짜고, 실제로 버그가 일어나고 가정이 틀리는 시점에서 그에 대한 테스트 코드를 작성한다.
개인적으로 생각하는 TDD의 문제점입니다. 1. 실제 돌려야 할 코드를 짜는 사람이 테스트 코드도 짠다. 2. 테스트 코드 자체에 문제가 있다면 결국 도돌이표. 3. 테스트 코드부터 만드느라 실제 코드를 만드는데 지장이 생기는 경우가 있다. 4. 그럼에도 코드의 질이 극적으로 좋아진다는 어떠한 근거도 찾을 수 없다.
와 진짜진짜 다뤄주셨으면 했던 주제네요 ㄷㄷ... 개인적으로는 이전회사에서 TDD를 정말 열심히 했는데요... 개발하면서 운영환경에서 문제가 생기지 않을것 같은 묘한 자신감들이 생기는 장점이 있었습니다. 그런데, 추가요구사항이 생길때마다 꽤 관리하기가 어렵더군요(제 개발실력이나, 디자인능력이 떨어져서 그런것이겠지만..) TDD에대한 포프님의 견해 야근 끝나고 꼭 들어봐야겠네요! 좋은 주제 다뤄주셔서 감사합니다!
포프형님 좋아하는 개발자입니다. TDD에 대한 말씀 무조건 공감하고 응원합니다. TDD가 이상적인 개발방법론이지만 실제 개발하고 꾸준히 개선하며 운영하다보면 업무에 엄청난 부담을 줍니다. 그 어떤 유명한 개발자분들도 TDD가 실패한 이유를 알고 있지만 용기내서 말하지 못하고 계셨는데 포프형님 의견 내주셔서 감사드려요. 그리고 유닛테스트 한 수 배워갑니다.
해외에서는 여러사람들이 이미 이야기했습니다. 그래서 실무에서는 많이 정리된 이야기를 한국에서 굳이 다시 약을 파시는 분들이 있더라구요. 대표적인 사람이 DHH였는데(글 제목: tdd is dead long live testing) 이 사람의 경험이 너무 지엽적이라고 평가절하하는 사람들이 있었고(근데 TDD 주창자들의 실무 경험은 더 없음...) 마이크로스프트 사에서 C#의 테스트 리드였던 에릭 거너슨(15년간 TDD 시도)의 #NoTDD란 글도 있죠(이 분에 대해서는 평가절하 못하니 적당히 무시하고 넘어가더라는..) 그리고 여전히 TDD를 하려고 하시지만 제가 언급했던 모든 문제들을 인정하고 방법을 찾으려고 하는 사람들의 발표도 꽤 있죠. (예. Ian Cooper의 TDD, where it went all wrong). 하지만 저 발표후 몇 년 뒤에도 여전히 TDD의 문제를 못고쳤다는 식으로 또 발표 한 것을 봤어요. 참고로 TDD는 이미 20년된 방법론입니다. 이런 큰 문제들을 아직도 언급하고 있다는 게 말이 안돼요 ㅜ.ㅡ
많은 인사이트를 얻게 되는 영상입니다. 너무 감사해요 ㅠ.ㅠ.. "TDD가 정말 기업의 가치에 직결되는가"에 대해 많은 의문을 갖고 있었는데 깨달음이 큽니다! 해당 영상에서 가장 마음에 와닿는 부분은 "그런걸 언제 하고 있어" 인 것 같습니다. 돈이 곧 시간이고 시간이 곧 돈인데 본인의 이득에 취해있는 개발자들이 많은 것 같습니다. 만약 본인이 TDD의 병적인 문화를 원한다면 냉정하게 객관적인 자료를 통해 회사를 상대로 설득할 수 있어야 한다고 생각합니다. 유닛 테스트는 말씀하신대로 필요한 적절한 부분에 적용하는 것이 좋다고 생각하며 여기서 말한 '적절한'이라는 기준에 대해 깊이 고민하는 것이 좋을 것 같습니다.
한국에 한정해보면, 외국에서 새로운 기법이 나오면 일단 영업에서 셋 중 하나로 접근합니다. 개발기간을 줄어요 or 유지보수가 쉬워요 or 견고해서 오래 써요. 셋 모두 결론적으로 비용절감 됩니다로 귀결됩니다. 이렇게 영업하면서 제안서 평가위원과 친밀도를 극한으로 올립니다. 우리나라 IT중 SI가 80%정도되는 것으로 알고 있습니다. 그 중 공공부문은 늘 큰손입니다. 한 업체가 저런 선제적인 활동으로 심사항목에 들어갈 동안 열심히 제안서 품질을 올리고, 다른 회사는 이 사실을 늦으면 5일전 빨라도 10일전에 알게되고 그러면 최초 영업한 회사가 수주합니다. 공공은 정부나 연관기관이기에 한번 들어가면 쫙 퍼지며 웬만해서는 바뀌지 않습니다. 문서결과물에 병적으로 집착하는 곳이라 고난의 행군이 시작됩니다. 비용줄이는 효과라 했으니 개발기간과 투입인원은 줄였는데 일을 많아지니 결과물인 시스템과 문서의 품질이 떨어지는 경우가 많았습니다. 시스템은 무상유지보수기간을 이용하고 문서는 폐기될 때까지 창고에 갇혀있게 되는 경우가 많습니다. 물론 제대로 활용되는 곳도 있을겁니다. 이 예는 SI 중에서도 제가 경험한 것에 한정된 얘기임을 밝혀둡니다.
일년정도 전에 코드 퀄리티를 systematic하게 유지 보수 할수 있게 하는 방법을 찾으며 tdd에 대해 알게되었죠. 여러 책과 강의를 보았습니다. 그 과정 중에 댓글중에 나오는 tdd전도사 같은 분의 강의도 있고 그 분이 모 스타트업 cto도 됐고 여러 유튜브 영상에 나와서 말하는 것들도 봤었죠. 개인적인 견해는 tdd진영 측에서 말하는 일부 부분들(구현하는 함수든 클래스의 명세를 더 정확히 할수 있고 유지 보수 측면에서 테스트 자동화를 이미 깔고 가기에 안정감을 얻을수 있다)은 동감이 가지만 테스트 작성을 어느 범위까지 해야하는 부분은 설명하는 사람마다 다르고 통일 되어 있지 않더라구요. 그리고 이 부분은 어지간히 숙련된 프로그래머가 아니면 스스로 범위를 규정짓기도 힘들고 구현하는 기능마다 달라지기도 하구요. 눈깜짝 할 새에 테스트만 구현 가능하면 나쁘지 않은 방법론 같지만 포프님 말씀처럼 그게 힘든것 같네요.
클래스 명세 부분은 사실 OOP와 함수의 선조건 후조건으로 해결해야할 부분인데 그걸 못하니 TDD로 해결하려는 거 같습니다. 근데 TDD로 해결하려다 보면 필요없는 인터페이스를 양산하게 되어 오히려 클래스의 의미가 모호해지는 부작용도 있죠. TDD 주창자인 kent beck도 자기는 무조건 인터페이스와 구현을 분리하려고 하는 성향이 있어서 TDD가 잘 맞을 뿐이라고 블로그 글을 쓴 적도 있죠. 프레임워크를 만들때는 인터페이스가 많이 분리되는 게 맞지만 응용프로그램 개발에서는 의문스러운 방법이죠
사람은 실수를 하기전에 자기가 어떤 실수를 할지 모른다.. 코드 뿐만 아니라 일반적인 상황에서도 적용되는 얘기인 것 같습니다. 아무리 노력하고 고민해도 실제 상황이 닥치기 전엔 알 수 없는 것들이 많더군요. 당연히 실수를 안하기 위해서 노력해야하지만, 실수를 100퍼센트 잡아낼 수 있다고 생각하는 건 환상이기 때문에 실수가 생길 수 있다는 걸 염두하고 살아가는게 맞는 것 같습니다.
그걸 미리 알면 버그라는 건 거의 존재하지 않아야겠죠. 따라서 버그를 만드는 걸 두려워하기보다, 그 버그가 빨리 발견되고 빨리 고칠 수 있는 코드 습관을 가지는 게 좋습니다. 어느 업계에서도 문제를 빨리 보고하고 빨리 고치는 사람이 일잘하는 사람이지 않습니까? TDD는 그런 통념에 오히려 반하지요.
07:25 지금까지 솔루션 회사에만 다녀봤는데요. (연차가 높진 않습니다.) 제가 다녀본 솔루션 회사들은 public으로 API나 라이브러리를 한 번 드러내면 breaking change를 거의 만들지 않으려 했습니다. 고객들이 솔루션 업데이트 했다가 자기 코드 깨지면 싫어하니까요. TDD 매니아라도 private 메소드까지 유닛 테스트를 하지는 않을테니 이런 경우엔 유용하다고 봅니다. 국내에 솔루션 회사 비중이 아주 적지도 않고요. 정작 서비스 스타트업에서 TDD에 열광하는 사람들이 제일 많은 이유는 저도 의문입니다.
맞습니다. 요구사항이 설계시부터 변하지 않는 기능들은 당연히 자동화 테스트를 넣는 게 좋습니다. (TDD가 아니라 API 호출 테스트 여도 말이죠) 참고로 말씀드리면 TDD에 심히 열광하는 사람들은 private 메서드까지 public 메서드로 만들고 유닛테스트에 mock을 끼워넣기 위해 필요없는 interface를 만들기도 합니다. (모든 클래스마다 인터페이스를 하나씩 만드는 사람들도 있죠)
마틴 파울러는 잘 모르겠지만 나머지 두 책의 저자는 굉장히 지엽적이고 비일반적인 본인 경험에 사용했던 방법을 일반적인 방법론으로 우기시는 분들이죠. 자기가 주창한 방법론에 대한 비판에 대해 명쾌한 해답을 내놓기보다 그냥 '나에겐 그냥 그게 더 좋아'라는 주관으로 정신승리하시는 분들...
세 가지 질문이 있습니다. 1. TDD에 대해 DHH가 인정한 부분은 동의하시는지요? - DHH는 TDD가 테스트가 없던 세계에서 테스팅의 세계로 인도했다고 말합니다. - 또 테스팅을 깊은 수준으로 할 수 있게 됐다고 합니다. - 또한 TDD를 죽여 무덤 위에서 춤을 추는 게 아닌, 공헌을 기리고, 다음 단계로 넘어가자 합니다. 즉 TDD 자체는 프로그래밍 역사에서 어느정도 역할을 했다는 뜻이겠지요. 2. TDD가 더 효율적이지 않다는 증거가 경험적으로 말고, 수치적으로 있는지요? TDD 측에서 이런 주장을 했고, 그들에게 입증 책임이 있어야 한다고 말씀하실 수 있습니다. 저도 TDD를 중요시하는 측 입증책임이 100배 더 크다고 생각합니다. 그러나 세상에 TDD가 더 효율적이지 않다는 실제 데이터가 있는지요. 이 업계에선 모르겠으나, 다른 학계에선 상대방 주장이 왜 틀렸는지 통계로 증명하는 일들을 봐왔습니다. TDD가 더 효율적이지 않다고 주장하는 수치로 나타난 자료가 있는지 궁금합니다. 3. 이제 이 업계에 발을 들이는 사람으로서 뭐가 맞는지 판단하기 힘듭니다. 그때 어떤 기준을 잡고, 방향을 선택해야할까요? 현재 말씀하신 TDD만해도 저와 같은 신입 입장에선 포프님이 맞는지, 다른 유명하신 분이 맞는지 아직 이성적으로 판단할 깜냥이 안 됩니다. 그저 직감적인 불편감은 들 수 있겠죠. 그래서 불편감을 묻어둔 채 윗 사람들이 하는 말을 묵묵히 따르는 것밖에 지금은 할 수 없습니다. 이제 시작하는 사람이 실제 현실에서 먹히는 기술인지 아닌지는 어떻게 판단할 수 있을까요? 실력있는 유명한 기업에서 그 방법론을 좋아하면, 유용하다 판단할까요?
저연차때부터 이런 주관을 갖기는 힘든 일일까요?(연차문제라기보다는 사람 성향의 문제?) 무엇보다 많은 사람들은 '뭐가 좋다더라'하거나 업계에 정착되면 보통 '좋은게 좋은거겠지'하고 무비판적으로 수용할것 같은데 TDD나 클린코드 맹신론 반박하실때마다 뚜렷한 주관과 혜안에 놀랍니다.
이상하단 느낌은 저연차부터 가지시는 분들이 많습니다만 누군가 거짓말을 한다고 지적하려면 많은 용기가 필요하죠. 어느정도 자리를 잡아야 그 용기가 생기는 거 같습니다. 한국의 프로그래밍 관련 약팔이 들이 조금 신기한게 이미 해외에서 한바탕 헤쳐먹고 정리된 방법론들을 몇년 뒤에 수입해 판다는 건데요... 다행히 전 여기서 그 과정들을 다 보고 여러 기업(소기업 대기업 포함)에서 그 방법론들을 다 경험하다보니 좀더 자신있게 말할 수 있는 것 같습니다.
동의합니다 내가 생각하던 값은 개발하면서 넣어서 눈으로 확인했으니 테스트코드를 작성하면 어지간하면 통과하겠죠..결국 모든 케이스를 상상해서 작업해야한단건데 그게되는 지능이면 굳이 테스트코드작성을 할 필요가 없죠 유저 db에서 데이터를 가져와 가공하는 코드을 짜는경우가 많아서 테스트 코드를 어떻게 작성하는게 좋냐는 아야기를 동료랑 해봤는데 유의미하게 테스트를 만드려면 더미 유저데이터를 꼼꼼하게 엣지케이스까지 생각해서 생성하는 담당자가 있어야 한다는 결론으로가서 불가능한 방법론이란 결론을 내린적있네요
"테스트를 안한다 -> 협업이 안된다" 라 생각합니다. 보통 협업 안되는 사람들은 문제를 숨기고 동료에게 떠넘길 생각을 베이스로 깔고 갑니다. 그러니 당연히 테스트로 걸러낼 생각을 안하죠. 물론 코드 리뷰나 동료검토는 뇌에 없구요. 8년차 개발자인데 슬슬 리더급으로 올라설 준비를 하니 협업 안되는 사람은 실력이 좋아도 왜 안쓰는지 알거 같습니다. 일전에 말씀하신 업무 퀄리티가 안나오는 사람, 그리고 일을 끝내지 못하는 사람들 특징 또한 테스트를 안하지요. 근데 재밌는건 이사람들은 본인이 "잘한다"라 생각하고 고집은 더럽게 쎄다는 거죠 ㅋㅋ
> 협업 안되는 사람은 실력이 좋아도 왜 안쓰는지 알거 같습니다. 덧글 쭉 보다가 이 부분 엄청 공감되서 리플답니다...ㅠㅠ 저는 리더가 아무리 이 친구 답 없다고 리포트를 해도 리더십을 키운답시고 바꿔주지도 않고 강제로 1년 넘게 붙여놓는 바람에 멘탈 날아가고 건강문제까지 생겨서 결국 팀 바꾸게 되었습니다 (거기에 덤으로 특정국가에 대한 불신감도...)
고봉밥 댓글하나 달아봅니다. 왜 TDD를 선호하는 사람이 있을까에 대해 좀 생각해봤는데요 (이 영상전에 TDD가 뭔지도 몰랐습니다) 사람 성향이 다르다고 해야하나 그런게 있는것 같아요 극단적으로 말하면 자기가 만든 코드에 대해 예측이 안되는거죠 딱 포프님이 얘기하신 객체지향 설계, 전체 로드맵이 머릿속에 없는 사람들입니다. 버그가 어느 구간에서 발생했는지 예측이 안된다 -> 버그를 못찾거나 찾는데 한세월 버그 없이 프로그램을 쌓을순 없을까? -> 오오 TDD라는 마법의 방법론이 있었다니?? 예를들어 통신선로 중 한 구간이 고장났다 A - B - C - D - E - F - G가 있을때 (F가 고장) A부터 순서대로 조사하는 사람 D부근에서 반을 나눠서 조사하는 사람 (벌써 전체 구조를 아는 사람임) 되게 단순한 구조의 예시인데 사회를 살면서 전자의 사람을 정말 많이 만납니다. 그리고 그들이 몇번의 가이드를 한다고해서 후자 처럼 된다는 경우는 많지 않습니다. 음......안타깝지만...TDD에 대한 강의들은 계속 잘팔릴듯......하네요
사전에 테스트 케이스를 다 짜놓는다는 마인드 자체가 말이 안되죠 ㅋ 시간도 불필요하게 더 들고.....나름 유행하고 뜬 이유가 쪼렙 개발자들 실수 방지로 상급자들 입장에서 스트레스 덜 받을 수 있어서 알려주고 밀어준걸로 패턴이나 방법론들에도 그런 류의 것들이 있던거 생각하면 이것도 같은 계열이라는 생각을 가지고 있네요
현직 자바개발자입니다.(아직 Si입니다ㅠ) 현재 이직준비중에 있고 서비스기업 면접을 보면 항상 "테스트"에 대한 질문이 나옵니다. 애석하게도 Si는 Tdd는 커녕 유닛테스트조차 안하죠 ㅠ 그래서 나도 Tdd기반의 프로젝트를 해야하나 의문을 가질때도 있었는데 우선은 다른거에 먼저 집중해야겠군요 ㅋㅋㅋ
이번에 스프링 찍어먹어보는 강의를 보면서 테스트 코드를 처음 만들어보았습니다. (개념이 있다는 건 알고 있었으나, 해보는 건 처음) 그러면서 함수 만들고 테스트 코드 작성까지 하고 강사님이, 테스트 코드부터 만드는게 TDD 방식이라 면서 소개했는데, 그때 듣고 좀 띠용 했었습니다. 그리고 스프링 강의인 만큼 자바로 테스트 코드 작성을 했는데, C#에서도 비슷한 개념이 있는가 구글링을 했는데, 알고리즘이 기가막히게 캐치해서 이 영상을 추천하네요 ㄷㄷ... 예전에도 이 영상을 봤지만, 반만 이해했었고, (아무튼 TDD는 그다지 좋은 방법은 아니라는 거지? 하고 넘어갔습니다.) 지금 보니까 정확하게 뭐가 문젠지 이해가 되네요... 함수 구현이 어떻게 진행될 지 모르는데, 테스트 코드부터 작성을 한다? 그럼 테스트만 통과하고 실제 사용할 때 예기치 못한 문제가 발생하면, 어쩌지? 하는 생각들이요... 그리고 애초에 이 테스트가 돌아가면, 함수가 적절히 동작한다는 것을 전제한다면 테스트 코드가 그만큼 정확하게 테스트 해야한다는 의미인데, 그걸 함수의 원리도 명확하게 정해지지 않은 상태에서, 그런 수준의 테스트 코드를 작성할 수 있을지도 의문이고요... 설계는 중요하지만 이는 어디까지나 요구사항과 구체적인 인터페이스작성 (그 외 더 명확한 의존성 관계 설정)과 같이 추상적인 부분에서 멈춰야지, 구체적인 동작 부분으로 들어가면 안된다고 생각합니다.
방법론이란게 사실 유행이자 하나의 이론이면서 방향인거지 그게 정답이거나 그것 자체가 목적이 아닌지라... 객체지향이나 애자일이나 MSA 나 사실 그런 구조나 방법의 장점들을 고려하면서 해라 정도로 이해하고 접근하는게 좋지 싶네요 이게 답이야 이제 이게 우리 표준이야 이런 결론이 좀 서로간 의견 차가 생기고 하는거지 싶습니다 객체지향의 원칙들도 객체지향의 배척점인 절차지향을 사용 하더라도 객체 가 아닌 함수 나 모듈 하나의 단위에서의 SOLID 원칙을 적용 할 수는 있음 같은 게 어떤 예가 되지않을까.. 합니다 c++ java 같은 언어가 아닌 객체지향 방법론을 안쓰는 언어나 프레임웍 에서도 아키텍쳐나 모듈 구현이나 설계를 할때 단일책임 이라던지 하는 내용을 염두하고 진행함은 객체지향 방법론을 적용하는것일까? 아닐까? 라는걸 선을 긋는것 자체가 불필요하죠..
맞습니다. 그런데 자꾸 주목 받으려고 새로운 방법은 silver bullet처럼 파시는 분들이 있네요... 솔직히 말하면 소프트웨어 개발방법도 이미 어느정도 자리를 잡은지라 획기적인 변화보다는 점진적은 개선이 일어나고 있습니다. 근데 아직도 획기적인 변화를 선도한 사람이 되고 싶어하는 사람들이 있는거 같아요...
1:36 요즘 TDD가 팔리나요? 언제쩍 이론이 한국에서는 지금도 팔리고 있는건가요 ㅡㅡ;; ㄷㄷㄷ 20년전에 TDD 써보고 이걸 실무에서 시간 낭비하면서 왜 쓰는지 전혀 사용성을 못 느껴서 버렸는데.... 시간만 더 들어가고 안정성이 좋아지지도 않으며 특히나 랜더링 쪽에는 적용도 불가능한 쓔레기 이론!!
TDD가 테스트 기법이 아니라고 하면서도 또 TDD = 테스트 라는 관점에서 반론을 제기하기도 하니... 좀 황당하죠.. 그냥 TDD에는 테스트와 개발의 두 측면이 있으며 유닛 테스트나 그 테스트를 통한 개발이나 둘다 효율은 별로 좋지 않지만 개발적인 측면에서 얻으려고 하는 건 제대로된 OO 설계지식으로 해결하는 게 더 근본적인 방법이죠
해당 영상은 TDD 관련 책을 1~2권을 읽고 Ruby를 만든 `TDD는 죽었다` 글을 볼시면 포프님의 말이 공감이 될거같습니다. 0:57 TDD를 통해서 설계적인 부분이 높아진다. TDD는 테스트 코드를 작성하고 해당 테스트를 통과하기 위해 기본적인 코드를 작성하고 리팩토링을 하므로서 설계적인 부분이 나아진다고 한다. 하지만 객체지향에 대한 SOLID 원칙 등 매커니즘을 이해를 했다면 설계적인 부분은 제외된다는 말씀 사람은 실수가 이미 default 이기에 테스트 코드를 작성한다는 것은 이미 실수가 내장이 되어있고 바뀌는거랑 잘 안바뀌는거 까지 테스트 코드를 만드는게 매우 비효율적, 바뀌는 것은 어차피 나중에 오류가 생기기 마련이고 그 때 유닛 테스트를 만들면 됨 그렇게 유닛 테스트를 만들다보면 자연스럽게 커버리지가 올라게됨 처음부터 여러 유닛테스트를 만들게되면 비즈니스 로직이 바뀔 때 마다 여러 유닛테스트 함수를 수정해야하므로 시간 낭비 돈 낭비 이다. 결론은 포프님은 TDD를 반대하는 거지 테스트를 반대하는게 아니라 테스트를 누구보다 사랑하는 분이다. 해당 영상을 이해하는데 3개월 걸렸네요. 좋은 영상 감사합니다.
TDD를 해보면 개발 생명주기와 설계적 의사결정의 타이밍이 완전히 변하게됩니다. 자꾸 버그와 문서화 관점에서 얘기하시는데, 그건 그냥 테스트 코드의 장점인것이구요. TDD를 잘 모르니 단순히 테스트를 먼저 작성하는 방식으로 TDD 애매하게 시도 한 이후, 이런 시각을 갖고계신 분들이 많습니다. 마틴파울러가 말했죠 TDD 부정적인 시각을 갖고있는 사람이 켄트백과 한시간 페어코딩하고 TDD예찬론자가 되었다고
생명주기와 설계적 의사결정 타이밍이 변한다는 사실 그 자체는 장점이 아닙니다. 아무개씨가 아무개씨와 페어프로그래밍을 해서 어떤 방법론의 예찬론자가 되었다는 것도 마찬가지고요. TDD가 나온지 십년도 훌쩍 지났으니 그로인해 일어난 측정가능한 장점들을 말해주시면 귀담아 듣겠습니다. 그리고 프로그래밍 실력이 많이 모자르신 분들이 자꾸 이런 무논리로 TDD가 좋다하시더라구요.
UI는 이미 seleneum (혹은 그 비슷한) 기반 UI 드리븐 자동화 테스트 기법이 존재합니다. 실제 굉장히 많이 사용하고요. End-to-end 방식의 인테그레이션 테스트의 일부로 처리하는 게 일반적이며, TDD의 유닛테스트로 해결할 문제는 거의 대부분 아닙니다. (유닛 테스트가 유효한 경우가 5% 미만이라 생각)
@@parkmin59 해외 정부 프로젝트에서 픽셀단위의 요구사항이 와서, 테스트코드부터 짜면서 tdd로 구현해나갔다는 이야기를 같이일하는분께 들었어요. 이 이야기가 tdd 같이 신나게 까다가, 이런 예외케이스가 있긴하다 정도로 나온거라, 포프님이 말씀하신 5%가 아닌가 싶습니다
![[TH] VALORANT Champions Seoul - Grand Final - EDG vs TH](http://i.ytimg.com/vi/WvObMc9VelI/mqdefault.jpg)
![[UNCUT] The Loyal Pin ปิ่นภักดิ์ EP.4 (2/4)](http://i.ytimg.com/vi/MN-p1DHjPtI/mqdefault.jpg)
![[10분 테코톡] 제이의 단위 테스트](/img/n.gif)
소프트웨어 개발, 테스팅 또한 경제적인 활동이다. 자원(시간, 인력)을 적게 투입하여 최대한의 효용을 뽑아내어야 한다
코드에 따라 유닛 테스트는 필요할 때도 있고 필요하지 않을 때도 있다. 유닛 테스트가 필요한 경우는 다음과 같다
1) 알고리즘이 매우 복잡하지만 수학적으로 잘 정의된 경우, 구현 상의 명백한 버그를 없애기 위해 필요하다
2) 제품이 실제로 사용되고 발전하면서 자꾸 변하거나 가정이 틀리는 부분의 버그를 없애기 위해 필요하다
1에서는 TDD가 어느 정도 유용할 수 있으나 2에서는 쓸모가 없다. 코드의 어떤 부분이 변경될지 예측하는 것은 어렵기 때문이다.
1은 애초에 안 변하고, TDD 방식으로 모든 코드에 대해 테스트를 짤 경우, 특히 2에서 코드를 변경해야하는데 테스트가 발목을 잡는다.
그러므로 (포프는) 제품 코드 전에 테스트 코드를 짜자는 TDD 방식을 쓰지 않는다.
일단 코드를 그냥 짜고, 실제로 버그가 일어나고 가정이 틀리는 시점에서 그에 대한 테스트 코드를 작성한다.
제가 이렇게 쉽게 요약할 수 있다면 비디오를 안 만들 것 같아요... 요약 잘해주셔서 감사합니다 :)
캬
캬... 이거 어디 복붙해놨다가 TDD예찬론자한테 고대로 써먹을게요
제가 말한 거라는 사실도 꼭 끼워넣어주세요. (정리가 잘 되어 있어서 제가 말했단 사실을 다 까먹을 거 같아 두렵...)
뭐가 옳고 그른지에 대해 이런 strong opinion을 가질 수 있는 것 자체가 부럽습니다...
저같은 무지렁이는 그냥 경험많은 분들은 이렇게 생각하시는구나~ 하는데 항상 구루분들의 의견이 참 큰 도움이 됩니다
항상 감사합니다
다양한 의견이 있는 건 좋죠. 하지만 그 의견들도 다 그 사람의 경험에 따른 게 많으니 어떤 사람이 근사한 이야기를 할 때는(그리고 그것에 대한 의문이 생길때는) 그 사람이 어떤 일을 해왔는지 한번 쭉 보시는 것도 좋습니다.
개인적으로 생각하는 TDD의 문제점입니다.
1. 실제 돌려야 할 코드를 짜는 사람이 테스트 코드도 짠다.
2. 테스트 코드 자체에 문제가 있다면 결국 도돌이표.
3. 테스트 코드부터 만드느라 실제 코드를 만드는데 지장이 생기는 경우가 있다.
4. 그럼에도 코드의 질이 극적으로 좋아진다는 어떠한 근거도 찾을 수 없다.
다 맞는 말씀입니다. 엔지니어라면 팩트에 근거해서 주장을 해야죠.
적극 동감 ㅋㅋㅋㅋ 그동안 공신력있는 사람들이 싸우기 싫어서 아무도 공식적으로 거론안했지만 ㅋㅋㅋ 포프님이 해주니 좋네여 ㅋㅋㅋ
저도 싸우기 싫습니다만 너무 이상한 소리만 많으면 옳은 이야기를 하는 사람도 필요하죠. 선택은 각자 알아서 할 일이구요 .
와 진짜진짜 다뤄주셨으면 했던 주제네요 ㄷㄷ...
개인적으로는 이전회사에서 TDD를 정말 열심히 했는데요... 개발하면서 운영환경에서 문제가 생기지 않을것 같은 묘한 자신감들이 생기는 장점이 있었습니다.
그런데, 추가요구사항이 생길때마다 꽤 관리하기가 어렵더군요(제 개발실력이나, 디자인능력이 떨어져서 그런것이겠지만..)
TDD에대한 포프님의 견해 야근 끝나고 꼭 들어봐야겠네요! 좋은 주제 다뤄주셔서 감사합니다!
그 자신감이 자기 방어기재가 되는 경우도 많이 봤습니다. 내 코드가 제대로 돈다는 확신은 다른 사람이 검증해줘야하는 거죠. 자동차 업계에서 안전 진단을 제조사가 아닌 다른 기관이 담당하는 것과 마찬가지 이치라 생각합니다.
포프형님 좋아하는 개발자입니다.
TDD에 대한 말씀 무조건 공감하고 응원합니다.
TDD가 이상적인 개발방법론이지만 실제 개발하고 꾸준히 개선하며 운영하다보면 업무에 엄청난 부담을 줍니다.
그 어떤 유명한 개발자분들도 TDD가 실패한 이유를 알고 있지만 용기내서 말하지 못하고 계셨는데
포프형님 의견 내주셔서 감사드려요.
그리고 유닛테스트 한 수 배워갑니다.
해외에서는 여러사람들이 이미 이야기했습니다. 그래서 실무에서는 많이 정리된 이야기를 한국에서 굳이 다시 약을 파시는 분들이 있더라구요.
대표적인 사람이 DHH였는데(글 제목: tdd is dead long live testing) 이 사람의 경험이 너무 지엽적이라고 평가절하하는 사람들이 있었고(근데 TDD 주창자들의 실무 경험은 더 없음...)
마이크로스프트 사에서 C#의 테스트 리드였던 에릭 거너슨(15년간 TDD 시도)의 #NoTDD란 글도 있죠(이 분에 대해서는 평가절하 못하니 적당히 무시하고 넘어가더라는..)
그리고 여전히 TDD를 하려고 하시지만 제가 언급했던 모든 문제들을 인정하고 방법을 찾으려고 하는 사람들의 발표도 꽤 있죠. (예. Ian Cooper의 TDD, where it went all wrong). 하지만 저 발표후 몇 년 뒤에도 여전히 TDD의 문제를 못고쳤다는 식으로 또 발표 한 것을 봤어요.
참고로 TDD는 이미 20년된 방법론입니다. 이런 큰 문제들을 아직도 언급하고 있다는 게 말이 안돼요 ㅜ.ㅡ
뭐 이미 15년전에 조을 스폴스키(스택 오버플로 공동 창업자, 예전에 마소에서 일함) 도 팟캐스트에서 했던 이야기죠.
많은 인사이트를 얻게 되는 영상입니다. 너무 감사해요 ㅠ.ㅠ.. "TDD가 정말 기업의 가치에 직결되는가"에 대해 많은 의문을 갖고 있었는데 깨달음이 큽니다! 해당 영상에서 가장 마음에 와닿는 부분은 "그런걸 언제 하고 있어" 인 것 같습니다. 돈이 곧 시간이고 시간이 곧 돈인데 본인의 이득에 취해있는 개발자들이 많은 것 같습니다. 만약 본인이 TDD의 병적인 문화를 원한다면 냉정하게 객관적인 자료를 통해 회사를 상대로 설득할 수 있어야 한다고 생각합니다. 유닛 테스트는 말씀하신대로 필요한 적절한 부분에 적용하는 것이 좋다고 생각하며 여기서 말한 '적절한'이라는 기준에 대해 깊이 고민하는 것이 좋을 것 같습니다.
화사의 목적을 이루기 보다는 자신의 책임회피를 위해 TDD를 좋아하시는 분들이 많습니다. 실제 동기가 다르니 회사에 합리적인 이유를 대기보다는 주관적이고 사상적인 이야기만 반복하게 되지요
학생입장에서 약팔이에 휘둘리기도 쉽고 그에따라 원칙을 정하기도 쉽지 않은데
본인의 원칙을 설명하면서 주제가 이러이러한게 원칙에 안맞는다~ 하시는게 도움이 많이 됩니다.
비즈니스 로직처럼 잘 바뀌는 부분이 아니라 유틸리티처럼 자주 사용되고 잘 바뀌지 않는 기능 위주로 테스트를 작성할 필요가 있겠네요
한국에 한정해보면, 외국에서 새로운 기법이 나오면 일단 영업에서 셋 중 하나로 접근합니다. 개발기간을 줄어요 or 유지보수가 쉬워요 or 견고해서 오래 써요. 셋 모두 결론적으로 비용절감 됩니다로 귀결됩니다. 이렇게 영업하면서 제안서 평가위원과 친밀도를 극한으로 올립니다. 우리나라 IT중 SI가 80%정도되는 것으로 알고 있습니다. 그 중 공공부문은 늘 큰손입니다. 한 업체가 저런 선제적인 활동으로 심사항목에 들어갈 동안 열심히 제안서 품질을 올리고, 다른 회사는 이 사실을 늦으면 5일전 빨라도 10일전에 알게되고 그러면 최초 영업한 회사가 수주합니다. 공공은 정부나 연관기관이기에 한번 들어가면 쫙 퍼지며 웬만해서는 바뀌지 않습니다. 문서결과물에 병적으로 집착하는 곳이라 고난의 행군이 시작됩니다. 비용줄이는 효과라 했으니 개발기간과 투입인원은 줄였는데 일을 많아지니 결과물인 시스템과 문서의 품질이 떨어지는 경우가 많았습니다. 시스템은 무상유지보수기간을 이용하고 문서는 폐기될 때까지 창고에 갇혀있게 되는 경우가 많습니다. 물론 제대로 활용되는 곳도 있을겁니다. 이 예는 SI 중에서도 제가 경험한 것에 한정된 얘기임을 밝혀둡니다.
tdd 도입한 si도 있나요? 좋은 곳이네요
이야... 진짜 너무 몰입하면서 봤습니다. 너무 너무 다뤄줘서 고마워요
봐주셔서 감사합니다. 좋으셨다면 구독과 널리 전파를... 😁
확정적이고 결정론적인 상황에서만 쓴다
맞죠 . 테스트 코드 자체가 사용 예제 설명서 역할도 하고
확정적인것과 그렇지 않은 것을 구별하고 설계하고 버전별로 분류하는 구조화 능력이 더 중요하네요
요즘 tdd강박 때문에 진도가 잘 안나갔는데 이 영상을 보고 깨닫고 가는 게 많습니다 감사합니다
TDD가 중요한 게 아니라 내가 작성한 코드를 검증하는 게 중요한 겁니다. 자기 코드를 손으로 테스트 못하시는 분들은 TDD에서 말하는 유닛 테스트 코드도 못 짜요 ㅠ
일년정도 전에 코드 퀄리티를 systematic하게 유지 보수 할수 있게 하는 방법을 찾으며 tdd에 대해 알게되었죠. 여러 책과 강의를 보았습니다. 그 과정 중에 댓글중에 나오는 tdd전도사 같은 분의 강의도 있고 그 분이 모 스타트업 cto도 됐고 여러 유튜브 영상에 나와서 말하는 것들도 봤었죠.
개인적인 견해는 tdd진영 측에서 말하는 일부 부분들(구현하는 함수든 클래스의 명세를 더 정확히 할수 있고 유지 보수 측면에서 테스트 자동화를 이미 깔고 가기에 안정감을 얻을수 있다)은 동감이 가지만 테스트 작성을 어느 범위까지 해야하는 부분은 설명하는 사람마다 다르고 통일 되어 있지 않더라구요. 그리고 이 부분은 어지간히 숙련된 프로그래머가 아니면 스스로 범위를 규정짓기도 힘들고 구현하는 기능마다 달라지기도 하구요.
눈깜짝 할 새에 테스트만 구현 가능하면 나쁘지 않은 방법론 같지만 포프님 말씀처럼 그게 힘든것 같네요.
클래스 명세 부분은 사실 OOP와 함수의 선조건 후조건으로 해결해야할 부분인데 그걸 못하니 TDD로 해결하려는 거 같습니다. 근데 TDD로 해결하려다 보면 필요없는 인터페이스를 양산하게 되어 오히려 클래스의 의미가 모호해지는 부작용도 있죠. TDD 주창자인 kent beck도 자기는 무조건 인터페이스와 구현을 분리하려고 하는 성향이 있어서 TDD가 잘 맞을 뿐이라고 블로그 글을 쓴 적도 있죠.
프레임워크를 만들때는 인터페이스가 많이 분리되는 게 맞지만 응용프로그램 개발에서는 의문스러운 방법이죠
@@포프티비 앗 포프님 선 보건의 뜻을 검색해도 잘 모르겠습니다 ㅠ 항상 잘보고 잇습니다 선 보건이 뭔지 궁금해서 여쭤봅니다
@herb 맞습니다. 오타였습니다. (auto correct ㅠ_ㅠ)
아는분이랑 성함이 비슷해서 깜짝놀랏네요
포프st > 소잃고 외양간 고치겠다. 탈출하는 곳만 다시 탈출못하도록 보수. 어차피 소는 탈출함. 소는 또 키우면 됨.
TDD > 소잃기 전에 울타리도 깔고 그물망도 깔고 철조망도 깔고 벽도 세우고 아 이런.. 외양간 확장할려니 다시 다 걷어내고 다시 깔고 그물망 깔고 철조망 깔고..... 휴 그래도 탈출하긴 어렵겠지~
java 쪽 특정 프레임워크 좋아하시는분들이 tdd도 광적으로 좋아하더군요 ㅋㅋㅋ. 어떤 버그가 일어날지 실패하는 테스트 코드를 먼저쓴다라... 그걸로 인해 버그가 난다면 그건 에초에 코드를 짜기전 비지니스 로직을 아예 이해하지 못한거 아닐까요.
그게 TDD에 대한 핵심 비판중 하나입니다. 구현자와 테스트 코드 작성자만 다르면 되는 일인데...
근데 또 생각해보면 TDD를 처음 만드신 분의 팀 구성에 QA가 없었던 거 같습니다. 프로그래머 몇명이 전부였다고 본 것 같네요. 그러면 예전에 프로그래머 3~4명으로 모든 걸 할때는 맞는 방법이었지만, 요즘의 일반적인 개발 환경에서는 또 안먹히는 방법일 수도 있죠 .
너무 감사해요!! 외부 강연으로 접해왔던 TDD는 너무 생산성이 떨어지는 느낌이 들어 절망적이었습니다
그 외부강연자가 여러 프로젝트를 해보지 못 한 사람인 경우도 많더라구요. TDD를 처음 만드신 분도 주류 소프트웨어 개발 환경과 다른 환경에서만 일하셨고 나중에 페이스북에서는 적응못하고 자기 방법이 맞다고 주장한다 짤리셨다고 알고 있고...
사람은 실수를 하기전에 자기가 어떤 실수를 할지 모른다.. 코드 뿐만 아니라 일반적인 상황에서도 적용되는 얘기인 것 같습니다.
아무리 노력하고 고민해도 실제 상황이 닥치기 전엔 알 수 없는 것들이 많더군요. 당연히 실수를 안하기 위해서 노력해야하지만, 실수를 100퍼센트 잡아낼 수 있다고 생각하는 건 환상이기 때문에 실수가 생길 수 있다는 걸 염두하고 살아가는게 맞는 것 같습니다.
그걸 미리 알면 버그라는 건 거의 존재하지 않아야겠죠. 따라서 버그를 만드는 걸 두려워하기보다, 그 버그가 빨리 발견되고 빨리 고칠 수 있는 코드 습관을 가지는 게 좋습니다.
어느 업계에서도 문제를 빨리 보고하고 빨리 고치는 사람이 일잘하는 사람이지 않습니까? TDD는 그런 통념에 오히려 반하지요.
경력이 찰수록 테스트는 중요하지만 TDD의 효용성은 동의하지 않게되는게 저도느끼는 부분입니다.
제가 느끼기에 테스트 코드를 짜는 이유 중 하나는 버그에 대한 히스토리를 남기는 것이라고 생각 됩니다~!! 좋은 동영상 인거 같아요!
이거 도움 되죠. 주석으로 어떤 버그를 고친 거였는지 버그 번호를 남겨도 좋습니다.
프로젝트를 리팩토링하면서 테스트코드는 짜야할것같은데 어디부터 어디까지 먼들어야할지 감이 안왔었는데 타이밍좋게 이런영상이 업로드 됐네요! 도움이 많이 됐습니다.
정말 공감되는 꿀팁이네요 감사합니다
07:25 지금까지 솔루션 회사에만 다녀봤는데요. (연차가 높진 않습니다.) 제가 다녀본 솔루션 회사들은 public으로 API나 라이브러리를 한 번 드러내면 breaking change를 거의 만들지 않으려 했습니다. 고객들이 솔루션 업데이트 했다가 자기 코드 깨지면 싫어하니까요. TDD 매니아라도 private 메소드까지 유닛 테스트를 하지는 않을테니 이런 경우엔 유용하다고 봅니다. 국내에 솔루션 회사 비중이 아주 적지도 않고요. 정작 서비스 스타트업에서 TDD에 열광하는 사람들이 제일 많은 이유는 저도 의문입니다.
맞습니다. 요구사항이 설계시부터 변하지 않는 기능들은 당연히 자동화 테스트를 넣는 게 좋습니다. (TDD가 아니라 API 호출 테스트 여도 말이죠)
참고로 말씀드리면 TDD에 심히 열광하는 사람들은 private 메서드까지 public 메서드로 만들고 유닛테스트에 mock을 끼워넣기 위해 필요없는 interface를 만들기도 합니다. (모든 클래스마다 인터페이스를 하나씩 만드는 사람들도 있죠)
TDD, 마틴 파울러의 리팩토링, 로버트 마틴의 클린코드.... 한국에서 java spring 하는데 이거 모른다고하면 실력없는 개발자 되는 현상. 도대체 누가 만든것인가!
마틴 파울러는 잘 모르겠지만 나머지 두 책의 저자는 굉장히 지엽적이고 비일반적인 본인 경험에 사용했던 방법을 일반적인 방법론으로 우기시는 분들이죠.
자기가 주창한 방법론에 대한 비판에 대해 명쾌한 해답을 내놓기보다 그냥 '나에겐 그냥 그게 더 좋아'라는 주관으로 정신승리하시는 분들...
세 가지 질문이 있습니다.
1. TDD에 대해 DHH가 인정한 부분은 동의하시는지요?
- DHH는 TDD가 테스트가 없던 세계에서 테스팅의 세계로 인도했다고 말합니다.
- 또 테스팅을 깊은 수준으로 할 수 있게 됐다고 합니다.
- 또한 TDD를 죽여 무덤 위에서 춤을 추는 게 아닌, 공헌을 기리고, 다음 단계로 넘어가자 합니다. 즉 TDD 자체는 프로그래밍 역사에서 어느정도 역할을 했다는 뜻이겠지요.
2. TDD가 더 효율적이지 않다는 증거가 경험적으로 말고, 수치적으로 있는지요?
TDD 측에서 이런 주장을 했고, 그들에게 입증 책임이 있어야 한다고 말씀하실 수 있습니다. 저도 TDD를 중요시하는 측 입증책임이 100배 더 크다고 생각합니다. 그러나 세상에 TDD가 더 효율적이지 않다는 실제 데이터가 있는지요. 이 업계에선 모르겠으나, 다른 학계에선 상대방 주장이 왜 틀렸는지 통계로 증명하는 일들을 봐왔습니다. TDD가 더 효율적이지 않다고 주장하는 수치로 나타난 자료가 있는지 궁금합니다.
3. 이제 이 업계에 발을 들이는 사람으로서 뭐가 맞는지 판단하기 힘듭니다. 그때 어떤 기준을 잡고, 방향을 선택해야할까요?
현재 말씀하신 TDD만해도 저와 같은 신입 입장에선 포프님이 맞는지, 다른 유명하신 분이 맞는지 아직 이성적으로 판단할 깜냥이 안 됩니다. 그저 직감적인 불편감은 들 수 있겠죠. 그래서 불편감을 묻어둔 채 윗 사람들이 하는 말을 묵묵히 따르는 것밖에 지금은 할 수 없습니다. 이제 시작하는 사람이 실제 현실에서 먹히는 기술인지 아닌지는 어떻게 판단할 수 있을까요? 실력있는 유명한 기업에서 그 방법론을 좋아하면, 유용하다 판단할까요?
저연차때부터 이런 주관을 갖기는 힘든 일일까요?(연차문제라기보다는 사람 성향의 문제?)
무엇보다 많은 사람들은 '뭐가 좋다더라'하거나 업계에 정착되면 보통 '좋은게 좋은거겠지'하고 무비판적으로 수용할것 같은데
TDD나 클린코드 맹신론 반박하실때마다 뚜렷한 주관과 혜안에 놀랍니다.
이상하단 느낌은 저연차부터 가지시는 분들이 많습니다만 누군가 거짓말을 한다고 지적하려면 많은 용기가 필요하죠. 어느정도 자리를 잡아야 그 용기가 생기는 거 같습니다.
한국의 프로그래밍 관련 약팔이 들이 조금 신기한게 이미 해외에서 한바탕 헤쳐먹고 정리된 방법론들을 몇년 뒤에 수입해 판다는 건데요... 다행히 전 여기서 그 과정들을 다 보고 여러 기업(소기업 대기업 포함)에서 그 방법론들을 다 경험하다보니 좀더 자신있게 말할 수 있는 것 같습니다.
동의합니다 내가 생각하던 값은 개발하면서 넣어서 눈으로 확인했으니 테스트코드를 작성하면 어지간하면 통과하겠죠..결국 모든 케이스를 상상해서 작업해야한단건데 그게되는 지능이면 굳이 테스트코드작성을 할 필요가 없죠
유저 db에서 데이터를 가져와 가공하는 코드을 짜는경우가 많아서
테스트 코드를 어떻게 작성하는게 좋냐는 아야기를 동료랑 해봤는데 유의미하게 테스트를 만드려면 더미 유저데이터를 꼼꼼하게 엣지케이스까지 생각해서 생성하는 담당자가 있어야 한다는 결론으로가서 불가능한 방법론이란 결론을 내린적있네요
"테스트를 안한다 -> 협업이 안된다" 라 생각합니다.
보통 협업 안되는 사람들은 문제를 숨기고 동료에게 떠넘길 생각을 베이스로 깔고 갑니다.
그러니 당연히 테스트로 걸러낼 생각을 안하죠.
물론 코드 리뷰나 동료검토는 뇌에 없구요.
8년차 개발자인데 슬슬 리더급으로 올라설 준비를 하니 협업 안되는 사람은 실력이 좋아도 왜 안쓰는지 알거 같습니다.
일전에 말씀하신 업무 퀄리티가 안나오는 사람, 그리고 일을 끝내지 못하는 사람들 특징 또한 테스트를 안하지요.
근데 재밌는건 이사람들은 본인이 "잘한다"라 생각하고 고집은 더럽게 쎄다는 거죠 ㅋㅋ
자존심마저 무너지면 남은 게 없다고 생각하는 거 같아요. 오늘도 화이팅 입니다.
@@포프티비 개발자로서 가져야하는 마인드 항상 잘 배우고 있습니다. 영원히 현역에서 좋은 영향 주시길 바래욥!
> 협업 안되는 사람은 실력이 좋아도 왜 안쓰는지 알거 같습니다.
덧글 쭉 보다가 이 부분 엄청 공감되서 리플답니다...ㅠㅠ
저는 리더가 아무리 이 친구 답 없다고 리포트를 해도 리더십을 키운답시고 바꿔주지도 않고 강제로 1년 넘게 붙여놓는 바람에 멘탈 날아가고 건강문제까지 생겨서 결국 팀 바꾸게 되었습니다
(거기에 덤으로 특정국가에 대한 불신감도...)
@@jeongyehan 빌런들을 보면서 내가 언젠가 널 뛰어넘어주마라는 마인드로 가시죠!
TDD = 테스트코드작성 이라는 이상한 오해가 생각보다 상당히 많더라구요. 그로 인해서 피해를 보셨던 것 같네요.. 항상 영상 잘 보고 있습니다. 감사합니다!
테스트 툴이나 테스트 방법론보다 먼저 로직부터 잘 이해하고 잘 만드는게 중요하
tdd 코드로 커버리지 높이기에는.. 개발자 몸값이 넘 비싸졌음 ㅠ
gui조작기반 qa자동화 프로그램들은 진짜 기본적인 기능들 반복테스트 해야될때, 가끔 쓰고잇는데 smartbear 같은거로 하면 비개발자 분들도 조작시나리오 설계수정이 가능하더라구요. 그나마 개발자인건비 대비 저렴하게 qa자동화 로직수정이 가능한거죠
네이버에서 gui테스팅설계 오픈소스로 guitar라는건 만들어서 가끔 썼었는데, 네이버가 바쁜지 안쓰는건지 요새는 업데이트를 안해줘서;
다른분들은 qa자동화 어떻게 하시는지 궁금하네요
고봉밥 댓글하나 달아봅니다.
왜 TDD를 선호하는 사람이 있을까에 대해 좀 생각해봤는데요 (이 영상전에 TDD가 뭔지도 몰랐습니다)
사람 성향이 다르다고 해야하나 그런게 있는것 같아요
극단적으로 말하면 자기가 만든 코드에 대해 예측이 안되는거죠
딱 포프님이 얘기하신 객체지향 설계, 전체 로드맵이 머릿속에 없는 사람들입니다.
버그가 어느 구간에서 발생했는지 예측이 안된다 -> 버그를 못찾거나 찾는데 한세월
버그 없이 프로그램을 쌓을순 없을까? -> 오오 TDD라는 마법의 방법론이 있었다니??
예를들어
통신선로 중 한 구간이 고장났다
A - B - C - D - E - F - G가 있을때 (F가 고장)
A부터 순서대로 조사하는 사람
D부근에서 반을 나눠서 조사하는 사람 (벌써 전체 구조를 아는 사람임)
되게 단순한 구조의 예시인데
사회를 살면서 전자의 사람을 정말 많이 만납니다.
그리고 그들이 몇번의 가이드를 한다고해서 후자 처럼 된다는 경우는 많지 않습니다.
음......안타깝지만...TDD에 대한 강의들은 계속 잘팔릴듯......하네요
대부분 저와 보는 관점이 같으십니다
@@포프티비 TDD에 대해 몰랐는데 찾아보고 의견을 달아보고, 포프님 관점과 같다는게 너무 기쁘군요. 모르는걸 알아가서 감사드립니다.
굉장히 특수한 지엽적인 경험"만" 한 개발자가 아닌한 보통 다 비슷하게 느끼고 계십니다. 그걸 정리를 잘 하시는 분들은 그만큼 남을 설득하기 위해 고민을 많이 해본 것일뿐 ^^
저도 비슷한 생각입니다. 버그를 보자마자 즉시 '아 그건가?' 전구가 번뜩이는 사람들이면 TDD같은 방법론이 굳이 필요하지 않을 것 같습니다.
수리적 센스가 떨어지면 TDD에, 국어적 센스가 떨어지면 클린코드, 디자인 패턴에 집착하게 된다고 봐요. 문제해결의 최단거리와 강건한 해결법을 알면 테스트코드를 짜야한다는 강박이 줄어들기 마련이고, 프로그램의 플롯과 역할을 분명히 하면 그게 읽기 쉬운 글이 되니까요.
포프님 그렇다면 코드를 리팩토링하거나 버그 픽스를 한 코드 후 회귀테스트는 인수 테스트로 커버하는걸까요?
자바/스프링 하고 있는데 좀 하면서 맞는가 싶기도하고.. 또 Test코드를 먼저 짤려고 하니 JUnit에서 모르는게 있으면 또 찾아봐야하느라
실제 구현 코드 못짜는 시간 늘고... 유닛 테스트를 많이 짜려고 하긴 하는데 TDD는 취준생 입장에선 아직 어렵네요 ㅠ
오랜만에 추천에 나와서 보게되었는데 예전 영상대비 어떻게 된게 시간이 갈수록 젊어지시는 것 같습니다. 뭔가 억울하고 부럽네요 ㅋㅋㅋ
사실 10년전에 미래를 내다보고 다 녹화해둔 겁니다!!! (는 거짓...)
사전에 테스트 케이스를 다 짜놓는다는 마인드 자체가 말이 안되죠 ㅋ 시간도 불필요하게 더 들고.....나름 유행하고 뜬 이유가 쪼렙 개발자들 실수 방지로 상급자들 입장에서 스트레스 덜 받을 수 있어서 알려주고 밀어준걸로 패턴이나 방법론들에도 그런 류의 것들이 있던거 생각하면 이것도 같은 계열이라는 생각을 가지고 있네요
실제 kent beck(TDD처음 주창하심)도 자기가 테스트 먼저 작성하는 이유가 '내 코드가 잘 작동한다는 자신감(confidence)을 가지고 싶어서'라고 했어요. 근데 내가 자신감을 가지는 것보다 남이 검증해줘서 확인받는 게 더 중요하죠.
현직 자바개발자입니다.(아직 Si입니다ㅠ)
현재 이직준비중에 있고 서비스기업 면접을 보면 항상 "테스트"에 대한 질문이 나옵니다.
애석하게도 Si는 Tdd는 커녕 유닛테스트조차 안하죠 ㅠ
그래서 나도 Tdd기반의 프로젝트를 해야하나 의문을 가질때도 있었는데 우선은 다른거에 먼저 집중해야겠군요 ㅋㅋㅋ
제대로 된 QA 하나 있는 게 더 도움이 됩니다.
TDD와 크게 상관없는 얘기긴 합니다만 유닛 테스트 내장 지원 해주는 언어나 프레임워크(Rust, Deno)의 경우 테스트 코드 작성도 편하고 좋더라고요.
TDD때문에 유닛테스트 프레임워크가 발전한거라면 그게 장점이 아닐까 싶네요. ㅋㅋㅋ
매우 큰 장점이죠. 그리고 유닛 테스트 프레임워크로 유닛 이상의 테스트도 할 수 있고요
왜 8년전영상이랑 6일전영상이랑 얼굴이 똑같지?? 왜 안늙으시지??!!!!!
8년전에 찍어놓은 영상입니다.. (응?)
테스트는 중요하지만 tdd가 만병 통치는 아니며 , tdd한다고 주객전도하지 말라는 말씀 같으신데 댓글에 본면 잘못 이해하시는 분들이 많으신 듯…
TDD는 테스트 코드 없이 잘 짜기 위해서 하는 것이다... (라는 말이 생각나네요)
키야 멋지십니다
진짜 나도 제일 공감하는게
아니 개발하기전에?
어떻게 테스트를 만들지?
이게 궁금했는데
그게 가능한 경우도 있긴 하죠. 일반적이지 않을뿐. 그 일반적이지 않은 걸 일반적이라고 우기는 게 문제
0:52
오늘도 잘 배워갑니다...
저도 TDD를 테스트한다는 느낌으로 쓰지 않고 부분만 실행해서 제대로 동작하는지 확인할때나 오류재현해서 디버깅할떄 씁니다.
개발이 끝나기전부터 클래스마다 Tdd를 자꾸하라고 징징거리는 동료에게보여주고싶은 영상이네요
주객 전도 되신 분들은 어딜가도 좀 문제죠
”이 영상은 규원님이 싫어합니다.“
그 분이 누구길래....
@@포프티비 약간 TDD 선봉장 같은 분 있어요 ㅎㅎ
@양북84 돈 잘 버시겠네요.
@@포프티비 강좌도 만드셨어요. 그렇다고 약 파는 분은 아니고, 스스로 옳다고 생각해서 실천하는 파이긴 합니다 ㅎㅎ
@양북84 좀 더 여러 분야에서 실천해보신 뒤 강좌를 만드시는 게 좋았을 거란 생각이 드네요. (사실 누군지 압니다. 저에게 예전에 밑도 끝도없이 쌍욕하셨던 분이라)
이번에 스프링 찍어먹어보는 강의를 보면서 테스트 코드를 처음 만들어보았습니다. (개념이 있다는 건 알고 있었으나, 해보는 건 처음)
그러면서 함수 만들고 테스트 코드 작성까지 하고 강사님이, 테스트 코드부터 만드는게 TDD 방식이라 면서 소개했는데, 그때 듣고 좀 띠용 했었습니다.
그리고 스프링 강의인 만큼 자바로 테스트 코드 작성을 했는데, C#에서도 비슷한 개념이 있는가 구글링을 했는데, 알고리즘이 기가막히게 캐치해서 이 영상을 추천하네요 ㄷㄷ...
예전에도 이 영상을 봤지만, 반만 이해했었고, (아무튼 TDD는 그다지 좋은 방법은 아니라는 거지? 하고 넘어갔습니다.) 지금 보니까 정확하게 뭐가 문젠지 이해가 되네요...
함수 구현이 어떻게 진행될 지 모르는데, 테스트 코드부터 작성을 한다?
그럼 테스트만 통과하고 실제 사용할 때 예기치 못한 문제가 발생하면, 어쩌지? 하는 생각들이요...
그리고 애초에 이 테스트가 돌아가면, 함수가 적절히 동작한다는 것을 전제한다면 테스트 코드가 그만큼 정확하게 테스트 해야한다는 의미인데, 그걸 함수의 원리도 명확하게 정해지지 않은 상태에서, 그런 수준의 테스트 코드를 작성할 수 있을지도 의문이고요...
설계는 중요하지만 이는 어디까지나 요구사항과 구체적인 인터페이스작성 (그 외 더 명확한 의존성 관계 설정)과 같이 추상적인 부분에서 멈춰야지, 구체적인 동작 부분으로 들어가면 안된다고 생각합니다.
좋은 개발론은 아키택트와 PM의 일을 강화시켜주는 개발론이지 일을 줄여주는 개발론이 아닌 것 같습니다.
좋은 영상 감사합니다!
잘봤습니댜😮
개발하다 TDD원칙에 따라 먼저 테스트코드 짜달라면 아..... 그냥 키보드 집어 던지고 나가해😮
Aㅏ~
이사람 말하는거보면 클린코드도 하지말라고 할거같네요. 공부 열심히 해야겠습니다. 자극받고 갑니다.
클린코드 책을 말씀하시는 거면 그 책에서 나온 내용에서 취할 부분과 버릴 부분이 있지만 일반적인 회사에서는 버릴 부분이 더 많습니다.
따라서 그 책 보다는 코드 컴플리트를 먼저 보시길 권해드립니다.
테스트는 많이! 그리고 효율적으로!
방법론이란게 사실 유행이자 하나의 이론이면서 방향인거지 그게 정답이거나 그것 자체가 목적이 아닌지라...
객체지향이나 애자일이나 MSA 나 사실 그런 구조나 방법의 장점들을 고려하면서 해라 정도로 이해하고 접근하는게 좋지 싶네요
이게 답이야 이제 이게 우리 표준이야 이런 결론이 좀 서로간 의견 차가 생기고 하는거지 싶습니다
객체지향의 원칙들도 객체지향의 배척점인 절차지향을 사용 하더라도 객체 가 아닌 함수 나 모듈 하나의 단위에서의 SOLID 원칙을 적용 할 수는 있음 같은 게 어떤 예가 되지않을까.. 합니다
c++ java 같은 언어가 아닌 객체지향 방법론을 안쓰는 언어나 프레임웍 에서도 아키텍쳐나 모듈 구현이나 설계를 할때 단일책임 이라던지 하는 내용을 염두하고 진행함은
객체지향 방법론을 적용하는것일까? 아닐까? 라는걸 선을 긋는것 자체가 불필요하죠..
맞습니다. 그런데 자꾸 주목 받으려고 새로운 방법은 silver bullet처럼 파시는 분들이 있네요... 솔직히 말하면 소프트웨어 개발방법도 이미 어느정도 자리를 잡은지라 획기적인 변화보다는 점진적은 개선이 일어나고 있습니다. 근데 아직도 획기적인 변화를 선도한 사람이 되고 싶어하는 사람들이 있는거 같아요...
썸네일 이건희회장님꺼 따라한거는 안비밀
저희 아버지라....
테스트하기 좋은 코드가 좋은코드죠
잘 짜여진 코드는 테스트하기도, 이해하기도, 확장하기도, 고치기도 편합니다. :)
가장 복잡한소프트웨어중 하나인 게임을 만드는데 테스트를 안할리가없죠 ㅎㅎ 역시 진정한 개발자 갓포프!
근데 의료기기 등의 분야에 비해 버그를 만들어도 좀 용서가 되는 분야기도 해서.... 그리 스트레스를 받진 않아요.. .^^
1:36 요즘 TDD가 팔리나요? 언제쩍 이론이 한국에서는 지금도 팔리고 있는건가요 ㅡㅡ;; ㄷㄷㄷ 20년전에 TDD 써보고 이걸 실무에서 시간 낭비하면서 왜 쓰는지 전혀 사용성을 못 느껴서 버렸는데.... 시간만 더 들어가고 안정성이 좋아지지도 않으며 특히나 랜더링 쪽에는 적용도 불가능한 쓔레기 이론!!
제 말이 말이죠... 지난 몇년간은 열심히 파는 한국인들이 있어요.
주객 전도 되지 말라는 뜻으로 받아들이면 될까요.
그렇습니다.
method와 methodology를 구분하지 못하면 수많은 병폐가 생기는듯 합니다.
TDD를 안좋아한다고 테스트를 대충한다는 뜻이 아닌데 말입니다...
TDD가 테스트 기법이 아니라고 하면서도 또 TDD = 테스트 라는 관점에서 반론을 제기하기도 하니... 좀 황당하죠..
그냥 TDD에는 테스트와 개발의 두 측면이 있으며 유닛 테스트나 그 테스트를 통한 개발이나 둘다 효율은 별로 좋지 않지만 개발적인 측면에서 얻으려고 하는 건 제대로된 OO 설계지식으로 해결하는 게 더 근본적인 방법이죠
이좀싸 주도 개발합니다.
이거
좀
싸할때 테스트
이좀싸테
충분히 경험이 많으면 어느 부분에서 더 테스트를 해야할지 알기도 하죠
선추천 후감상~ 혹시 포프티비 디스코드는 어떻게 들어갈 수 있나요?
유튜브 채널에서 멤버쉽 가입하면 들어올 수 있어요 (유료. 무려 한달에 990원)
실용주의 TDD로 들리네요
실무에서 사용하는 유닛테스트 방법이라 봐주세요 :)
해당 영상은 TDD 관련 책을 1~2권을 읽고 Ruby를 만든 `TDD는 죽었다` 글을 볼시면 포프님의 말이 공감이 될거같습니다.
0:57
TDD를 통해서 설계적인 부분이 높아진다.
TDD는 테스트 코드를 작성하고 해당 테스트를 통과하기 위해 기본적인 코드를 작성하고 리팩토링을 하므로서 설계적인 부분이 나아진다고 한다.
하지만 객체지향에 대한 SOLID 원칙 등 매커니즘을 이해를 했다면 설계적인 부분은 제외된다는 말씀
사람은 실수가 이미 default 이기에 테스트 코드를 작성한다는 것은 이미 실수가 내장이 되어있고 바뀌는거랑 잘 안바뀌는거 까지 테스트 코드를 만드는게 매우 비효율적,
바뀌는 것은 어차피 나중에 오류가 생기기 마련이고 그 때 유닛 테스트를 만들면 됨 그렇게 유닛 테스트를 만들다보면 자연스럽게 커버리지가 올라게됨 처음부터 여러 유닛테스트를 만들게되면 비즈니스 로직이 바뀔 때 마다 여러 유닛테스트 함수를 수정해야하므로 시간 낭비 돈 낭비 이다.
결론은 포프님은 TDD를 반대하는 거지 테스트를 반대하는게 아니라 테스트를 누구보다 사랑하는 분이다.
해당 영상을 이해하는데 3개월 걸렸네요.
좋은 영상 감사합니다.
신작 ㅎㄷㄷ
포프님 고언어, 러스트의 미래는 둘다 좋다고 생각하시나요?
고 언어는 처음부터 별로라고 말했습니다. 러스트는 좋은 언어라고 했고요
@@포프티비 고 언어가 별로라고 생각하시는 이유가 무엇인지 궁금합니다!
핫태핫태...!!
TDD를 해보면 개발 생명주기와 설계적 의사결정의 타이밍이 완전히 변하게됩니다. 자꾸 버그와 문서화 관점에서 얘기하시는데, 그건 그냥 테스트 코드의 장점인것이구요.
TDD를 잘 모르니 단순히 테스트를 먼저 작성하는 방식으로 TDD 애매하게 시도 한 이후, 이런 시각을 갖고계신 분들이 많습니다.
마틴파울러가 말했죠 TDD 부정적인 시각을 갖고있는 사람이 켄트백과 한시간 페어코딩하고 TDD예찬론자가 되었다고
생명주기와 설계적 의사결정 타이밍이 변한다는 사실 그 자체는 장점이 아닙니다. 아무개씨가 아무개씨와 페어프로그래밍을 해서 어떤 방법론의 예찬론자가 되었다는 것도 마찬가지고요.
TDD가 나온지 십년도 훌쩍 지났으니 그로인해 일어난 측정가능한 장점들을 말해주시면 귀담아 듣겠습니다.
그리고 프로그래밍 실력이 많이 모자르신 분들이 자꾸 이런 무논리로 TDD가 좋다하시더라구요.
출근길 감사합니다(?) 선댓후감상
진짜어렵다..ㅠ
😊
이게 맞지ㅋㅋ 시간이 쳐 남아돌아서 모든 소스를 병적으로 다 테스트 코드로 짜놓는 ㅂㅅ같은 개발자들은 제발 좀 사라졌으면 좋겠다. 안되는거 올려놓고 테스트 하라고 만든기능 가지고 모든걸 상정하겠다고 더미데이더 똥밭을 정성스럽게 만드는 기이한현상이 요즘 유행하고있음ㅋㅋㅋ
UI까지 tdd를 해야한다는 정신나간 소리를 하는사람들이 있더라구요
그래야 다른 일 하면서 자기들이 코딩 못하는 걸 숨길 수 있으니까요.
@@lohaswinner UI까지 TDD는 그냥 미친 짓이라고 생각하는데요. 테스트코드부터 치고 뷰를 짜는 그런 행위가 어떠한 비용을 줄여주는 지 그 상황이 뭔지 알려주실수있나요?
UI는 이미 seleneum (혹은 그 비슷한) 기반 UI 드리븐 자동화 테스트 기법이 존재합니다. 실제 굉장히 많이 사용하고요.
End-to-end 방식의 인테그레이션 테스트의 일부로 처리하는 게 일반적이며, TDD의 유닛테스트로 해결할 문제는 거의 대부분 아닙니다. (유닛 테스트가 유효한 경우가 5% 미만이라 생각)
@@lohaswinner 그런 스냅샷테스트는 유닛테스트가 아니잖아요. 테스트코드를 작성하지 않는데 tdd와 상관이있나요?
@@parkmin59 해외 정부 프로젝트에서 픽셀단위의 요구사항이 와서, 테스트코드부터 짜면서 tdd로 구현해나갔다는 이야기를 같이일하는분께 들었어요. 이 이야기가 tdd 같이 신나게 까다가, 이런 예외케이스가 있긴하다 정도로 나온거라, 포프님이 말씀하신 5%가 아닌가 싶습니다
기업 면접에서 TDD 약팔이는 왜 많은건지...
이걸 함정을 이용하는 기업 이야기를 최근에 들었는데.. 그 썰도 나중에 한번 풀어볼게요
1:45초 즘에 오디오가 이상하네요
조금 뛰었는데 어떻게 고칠지 몰라서....
즉 서비스 배포전 핵심적인 부분과 버그가 일어난 부분만 테스트를 만들어서 하라는 이야기군요
가장 효율적인 방법이죠. 그외에 시간과 돈이 남는다면 좀더 테스트 만드셔도 됩니다. 하지만 그보다는 전문 테스터를 채용하는게 가성비가 더 높을 겁니다.
저는 TDD를 처음 봤을때 너무 싫었어요 테스트 주도 개발이라니… 그럼 이전에는 테스트를 안했다는건가?? 그게 자랑이란듯이 이야기 한다고?
그전에도 테스트를 했으나 이제는 테스트 코드를 먼저 작성하고 그 테스트 코드에 맞게 구현하라는...
하지만 또 TDD에 대해 비판하면 그럼 테스트를 안할 거냐고 거품을 무는 사람들이 있으니 사실 그 전에는 테스트를 안하고 있었을지도...
@@포프티비 오늘도 포프님 혜안이 무릎을 탁치고 갑니다
2빠?
1빠