💬 오늘 영상에 대한 여러분의 생각은? 이번 영상에서는 Bob Martin과 Jim Coplien이 *테스트 주도 개발(TDD)* 의 중요성에 대해 깊이 있는 토론을 나눴습니다. > 여러분은 TDD가 소프트웨어 개발에 필수적이라고 생각하시나요? > TDD가 개발자의 프로페셔널리즘의 기준이 될 수 있다고 생각하시나요? 댓글로 여러분의 생각과 경험을 공유해 주세요! TDD에 대해 함께 이야기해 봅시다! 😊
jim의 언급처럼, 비지니스 요구사항이 api나 객체 단위와 직접적으로 연결될 수 없습니다. 유닛테스트는 적당한 수준에서 해야 하는 것이지, 유닛테스트가 개발을 주도할 수는 없다고 봅니다. 테스트 코드 커버리지에 목숨거는 프로젝트 운영에 반감이 있습니다. 비지니스 요구사항을 달성하는 software feature의 테스트를 중심에 두는 BDD가 현실적이고 효과가 좋다고 생각합니다.
저는 개인적으로 용어를 재 정의해서 쓰는데 Jim이 말한 코딩 완료시점에 그것을 테스트하는 테스트 코드가 있어야 한다는 방식을 실용중의 TDD라고 하고 Bob이 말하는 언제나 테스트코드를 먼저 작성해야 한다는 방식을 원리주의 TDD라고 부릅니다. Bob과 같은 원리주의자들의 문제점은 이 원리주의 TDD에 반대하는 것을 테스트에 반대하는 것으로 이야기 한다는거죠. 테스트는 TDD가 아닙니다.
너무 재밌는 내용이었습니다. 저는 TEST는 필수지만 TDD는 필수가 아니다 라는 관점에서, 테스트는 단순 커버리지 보다는 비지니스 로직에 맞게 결국 어떻게 의미있게 잘짜냐 중요한데 효율성이라는 관점에서 jim이 말한 계약 중심으로 바라보는 CDD가 효율적으로 보이는데요. 요즘은 AI 덕분에 실제 코드량과 단위테스트 코드량이 같다고 하지만 생산하는 시간 자체가 0에 가까워 지기 때문에 어느정도 기계적인 TDD를 진행하는것 자체도 나쁠건 없다 라는 생각이 들기도 합니다.
사실 좀 도전적인 로직이 첨가됐을 때는 TDD가 꽤나 유용하다고 보지만, 일반적인 로직에 TDD는 좀 아니라는 생각이 듭니다. 실제적으로 형식적인 테스트 코드 작성이 많아지게 되고 이는 생산성을 떨어뜨리게 되는 가능성을 안고 도입하게 됩니다. 개인적으로는 어떤 프로그램이 작성하게 되면 그 프로그램이 실제적으로 잘돌아가는 지에 대해 테스트 목록을 작성해서 그 리스트 항목에 맞춰서 테스트를 체크 해 나가는 게 개인적으로는 버그도 덜 발생하게 되고 프로그램에서 테스트가 빠진게 있는 지를 더 쉽게 확인해 볼 수 있었던 것 같습니다.
둘다 성격 진짜 부담스러운데 Jim 쪽이 더 ㅎㄷㄷ 하네요 ㅎㅎ 개인적으로 Jim 의견에 동의합니다. 보다 다방면에서 검토하면서 실질적으로 문제 해결이 이루어지는 쪽인 것 같네요. 돈도 확실히 Jim이 잘 벌것 같고...능력이 딸려서 그런가 확실히 테스트 작성하면서 코드가 복잡해지면서 관리가 안됐던 경험이 많았어서... 그러나 배포전에 반드시 초반에 언급한 테스트 원칙을 가능한 지키도록 하는 것은 필요한 것 같네요. Test Driven에 집착하면서 테스트 위주로 하는 것은 너무 교조적인 것 같구요.
저도 TDD의 유닛테스트에 집착하는 방식으로는 스노비즘에 걸린 쓰레기코드만 양산될 뿐이라고 봅니다. 시스템 기능을 테스트 할 수 있어야 하지요. 어떤 언어가 제공하는 기능을, 테스트코드 노르마를 때우기 위해, 소프트웨어 유닛테스트에 구겨넣고, 그걸 묵인하는 미친 프로젝트들을 너무 많이 봐왔습니다.
TDD는 나쁘지 않은데 문제는 TDD는 갑이다 하는 게 문제임. 그리고 저건 조직에 머지팀이 있는 경우에는 TDD가 적합함. 없는 경우는 걍 유닛테스트 많이 돌려보면서 가다듬거나 결함 찾는게 나음 근데 문제는 가끔 가다가 경력직 왔는데 뇌내 테스트만에 코드 올리니 TDD 하자고하는 거라 생각함
Tdd 개념자체는 참고할 만하다고 생각 하는데 신봉자 광신도 한놈이 팀에 있으면 아주 개판됨. 지금 당장 고객 피드백을 수정해야 하는데 뜬구름 잡는 tdd 이상론 부터 이야기 함. Tdd는 하기 싫다고 하면 테스트 코드 왜 작성 안하냐고 함. tdd와 테스트 코드를 동일시 하기 까지 함. tdd가 싫다 했지 테스트코드 싫다고는 안했는데 마치 자신의 소중한 가족을 부정당한듯한 모습. 면접에서 tdd 좋아하냐고 물어보고 광신도 끼보이면 탈락시켜야 함
![[마틴 파울러] 리팩토링의 중요성 feat.테스트 코드를 짜는 이유(한글 자막)](http://i.ytimg.com/vi/mNPpfB8JSIU/mqdefault.jpg)
![[마틴 파울러] 리팩토링의 중요성 feat.테스트 코드를 짜는 이유(한글 자막)](/img/tr.png)
![[마틴 파울러] 소프트웨어 아키텍처의 중요성 (한글 자막)](http://i.ytimg.com/vi/4E1BHTvhB7Y/mqdefault.jpg)
![[여사친] 대선후보 첫 토론회 명장면을 모아봤다 / 조선일보](/img/n.gif)
💬 오늘 영상에 대한 여러분의 생각은?
이번 영상에서는 Bob Martin과 Jim Coplien이 *테스트 주도 개발(TDD)* 의 중요성에 대해 깊이 있는 토론을 나눴습니다.
> 여러분은 TDD가 소프트웨어 개발에 필수적이라고 생각하시나요?
> TDD가 개발자의 프로페셔널리즘의 기준이 될 수 있다고 생각하시나요?
댓글로 여러분의 생각과 경험을 공유해 주세요! TDD에 대해 함께 이야기해 봅시다! 😊
멋진 영상과 자막 감사합니다!
jim의 언급처럼, 비지니스 요구사항이 api나 객체 단위와 직접적으로 연결될 수 없습니다. 유닛테스트는 적당한 수준에서 해야 하는 것이지, 유닛테스트가 개발을 주도할 수는 없다고 봅니다. 테스트 코드 커버리지에 목숨거는 프로젝트 운영에 반감이 있습니다. 비지니스 요구사항을 달성하는 software feature의 테스트를 중심에 두는 BDD가 현실적이고 효과가 좋다고 생각합니다.
5년차 개발자입니다. 수준높은 대화에 입이 떡 벌어지고 아직 공부하고 배워나가야 할 것이 너무 많다고 느끼네요 좋은 영상 감사합니다.
저는 개인적으로 용어를 재 정의해서 쓰는데 Jim이 말한 코딩 완료시점에 그것을 테스트하는 테스트 코드가 있어야 한다는 방식을 실용중의 TDD라고 하고 Bob이 말하는 언제나 테스트코드를 먼저 작성해야 한다는 방식을 원리주의 TDD라고 부릅니다.
Bob과 같은 원리주의자들의 문제점은 이 원리주의 TDD에 반대하는 것을 테스트에 반대하는 것으로 이야기 한다는거죠. 테스트는 TDD가 아닙니다.
와… 나는 프로그래머다 너무 재밌게 들었고 근황 궁금했었는데 이런 댓글이. ㅠㅠㅠㅠㅠ 내적친밀감과 반가움에 댓글달아보네요 :)
너무 좋은 내용이네요. 감사합니다.
TDD는 방법론이므로 소프트웨어 개발의 필수의 영역은 될 수 없다고 봅니다.
다만 수준 높은 프로젝트는 자동화된 셀프 테스트 기능을 가져야 하지 않을까 싶네요.
프로라면 그런 프로젝트를 지향해야 할 것이고요.
너무 재밌는 내용이었습니다. 저는 TEST는 필수지만 TDD는 필수가 아니다 라는 관점에서, 테스트는 단순 커버리지 보다는 비지니스 로직에 맞게 결국 어떻게 의미있게 잘짜냐 중요한데 효율성이라는 관점에서 jim이 말한 계약 중심으로 바라보는 CDD가 효율적으로 보이는데요. 요즘은 AI 덕분에 실제 코드량과 단위테스트 코드량이 같다고 하지만 생산하는 시간 자체가 0에 가까워 지기 때문에 어느정도 기계적인 TDD를 진행하는것 자체도 나쁠건 없다 라는 생각이 들기도 합니다.
바쁘셨을텐데 번역해주셔서 감사합니다!
덕분에 좋은 영상 시청합니다
사실 좀 도전적인 로직이 첨가됐을 때는 TDD가 꽤나 유용하다고 보지만, 일반적인 로직에 TDD는 좀 아니라는 생각이 듭니다. 실제적으로 형식적인 테스트 코드 작성이 많아지게 되고 이는 생산성을 떨어뜨리게 되는 가능성을 안고 도입하게 됩니다. 개인적으로는 어떤 프로그램이 작성하게 되면 그 프로그램이 실제적으로 잘돌아가는 지에 대해 테스트 목록을 작성해서 그 리스트 항목에 맞춰서 테스트를 체크 해 나가는 게 개인적으로는 버그도 덜 발생하게 되고 프로그램에서 테스트가 빠진게 있는 지를 더 쉽게 확인해 볼 수 있었던 것 같습니다.
너무 관심있는 주젠데 선댓글 후감상합니다 감사합니다!
둘다 성격 진짜 부담스러운데 Jim 쪽이 더 ㅎㄷㄷ 하네요 ㅎㅎ 개인적으로 Jim 의견에 동의합니다. 보다 다방면에서 검토하면서 실질적으로 문제 해결이 이루어지는 쪽인 것 같네요. 돈도 확실히 Jim이 잘 벌것 같고...능력이 딸려서 그런가 확실히 테스트 작성하면서 코드가 복잡해지면서 관리가 안됐던 경험이 많았어서... 그러나 배포전에 반드시 초반에 언급한 테스트 원칙을 가능한 지키도록 하는 것은 필요한 것 같네요. Test Driven에 집착하면서 테스트 위주로 하는 것은 너무 교조적인 것 같구요.
Bob이 얘기하는 극단적인 테스트 방법론은 처음 들었을 때 꽤나 매력적으로 들림.
하지만 Jim이 얘기하는 것처럼 실용주의적 사고를 조금만 해보면 금방 이성적인 사고를 할 수 있게 되돌아옴.
저도 TDD의 유닛테스트에 집착하는 방식으로는 스노비즘에 걸린 쓰레기코드만 양산될 뿐이라고 봅니다.
시스템 기능을 테스트 할 수 있어야 하지요.
어떤 언어가 제공하는 기능을, 테스트코드 노르마를 때우기 위해, 소프트웨어 유닛테스트에 구겨넣고, 그걸 묵인하는 미친 프로젝트들을 너무 많이 봐왔습니다.
TDD는 나쁘지 않은데 문제는 TDD는 갑이다 하는 게 문제임. 그리고 저건 조직에 머지팀이 있는 경우에는 TDD가 적합함.
없는 경우는 걍 유닛테스트 많이 돌려보면서 가다듬거나 결함 찾는게 나음
근데 문제는 가끔 가다가 경력직 왔는데 뇌내 테스트만에 코드 올리니 TDD 하자고하는 거라 생각함
좋은 영상 번역 공유해주셔서 감사합니다!
영상을 아직 다 보진 못했는데 3:10에 procedural bottom-up architecture 부분은 '절차적 상향식 아키텍쳐'라고 번역하는게 맞지 않을까요?
국내에서 TDD를 한다고 깝치는 새끼는 많지만 제대로 하는놈은 단 한번도 못본듯
이게 ㄹㅇ ㅋㅋ
안타깝게도 이게 현실임.. 나도 이제 10년쯤 되가지만 20년 30년 나름 왕년에 난다 긴다하신 분들도 제대로 하는걸 본적이 없음
작가와 개발자의 토론
원본 영상은 몇년전건가요?
12년 전 이야기군요.
개발을 누가 더 잘하는지는 모르겠고 리더에 어울리는건 JIM이고 Bob같은 새끼한테 맏기면 안된다는거
입장이 너무 다른 것 같은데요
자바-비지니스 현업 개발자와 C++ 뜬구름 개발자
누가 현업이고 누가 뜬구름이에요?
Tdd 개념자체는 참고할 만하다고 생각 하는데 신봉자 광신도 한놈이 팀에 있으면 아주 개판됨. 지금 당장 고객 피드백을 수정해야 하는데 뜬구름 잡는 tdd 이상론 부터 이야기 함.
Tdd는 하기 싫다고 하면 테스트 코드 왜 작성 안하냐고 함. tdd와 테스트 코드를 동일시 하기 까지 함. tdd가 싫다 했지 테스트코드 싫다고는 안했는데 마치 자신의 소중한 가족을 부정당한듯한 모습. 면접에서 tdd 좋아하냐고 물어보고 광신도 끼보이면 탈락시켜야 함
둘 다 사짜