좋은 내용의 글을 쓰시면서 왜 그렇게 태도는 공격적으로 일관하시는지 모르겠습니다.

말씀대로 소프트웨어 분야에 '은탄환'은 없고 모든 것은 트레이드 오프입니다. 그런데 그런 말씀을 하면서 "뭐? TDD를 안한다고? 그건 니가 실력이 부족한거야", "뭐? 단위테스트 비용이 큰 경우가 있다고? 설계를 잘못했네. 공부나해" 이래 버리면 그건 스스로의 주장을 부정하는 것이라는 생각은 안하시나요?

그리고 테스트 관련 논쟁을 얼마나 보셨는지 모르겠습니다만, 모든 코드를 단위 테스트하라는 건 실제로 그런 주장을 하는 사람들이 꽤 있습니다. 테스트의 중요성이 부각되기 시작한 초기엔 흔한 주장이었고 지금도 테스트 커버리지에 집착하는 경우는 얼마든지 볼 수 있습니다. (더구나 TDD까지 가면 테스트 없는 코드가 존재할 수 있던가요?)

또한 제가 적은 덧글에 대해 동의하지 않는 부분이 있다면 그 글에서 구체적 부분을 인용해서 생각이 다른 내용을 풀어주시면 될 일입니다. 다른 글을 파서 제 덧글 내용을 언급하면서 '미친짓'이라는 둥 공부를 더 하라는 둥 하는 건 참 비겁하군요.

참고로 CSS를 일일이 테스트하는건 단순히 테스트 기법이 확립되지 않은 예로 든 것입니다만, 처음 단위테스트가 등장했을 때는 셀레니엄 같은 식으로 브라우저를 제어하는 테스트 자동화도 비슷한 수준의  '미친짓'이었습니다. 지금 알고 있는 수준으로 미래를 예단할 이유는 없다고 봅니다.

어쨌건, 원하시는 것이 토론인지 계도인지 모르겠습니다만, 어느 쪽이 건 좀 열린 태도를 보여주시면 더 효과가 좋지 않을까 싶습니다.

굳어져있는 상태를 변화시키려면 자극적인 방법이라도 감행하는 분들이 계시죠.

안하는 습관이 이미 굳어진 현 사회 환경을 변화시키려고 자극적이게 말씀하시는거 같아요.

참고로 전에 동적으로 브라우저에서 SVG를 조작해서 차트를 만드는 API를 테스트하기 위해 직접 만든 테스트 도구의 스크린샷입니다. 스칼라.js에 스칼라테스트 지원이 들어가기 이전엔 직접 오픈소스로 간단한 테스팅 프레임워크를 만들어서 사용하기도 했습니다:

코드 상에서 오류가 없어도 눈으로 보이는 모양이 틀어지는 회귀는 얼마든지 발생할 수 있고, 프로젝트 성격에 따라 이런 식의 비주얼 테스트가 중요한 경우는 얼마든지 있습니다.

단위 테스트나 TDD의 효용성에 대해 본인 주장에 100% 동의하지 않으면 다 테스트나 설계를 잘모르는 것이라거나, 본인이 생각에 어렵거나 복잡할 것 같은 테스트는 다 '미친짓'이라는 식의 생각은 안하셨으면 좋겠습니다.

저는 "억지로"가 아닌 TDD어야만 그 역할을 다 할 수 있다고 생각합니다.
엔지니어들이 시스템을 모니터링 할 때나 네트워크의 안정성을 볼 때도 그 장비에 맞는 모니터링 도구와 장비, 소프트웨어들을 필요한 부분에 사용하게 됩니다. 억지로 끼워넣는다고 그게 정상적인 모니터링이 될 순 없으니까요. 전 TDD도 동일하다고 생각합니다.

참고로 테스트 자동화와 TDD는 좀 범주가 다릅니다. TDD는 단위 테스트를 개발 방법론으로 확장한 개념이며, 단위 테스트에 비해 호오가 갈리는 편입니다.

제 느낌은 대략 테스트 자동화의 유용함에 대해서는 (비록 비용과 효용에 대한 논의는 시작 단계임에도 불구하고) 거의 공감대가 형성되어 있는 반면, TDD는 회의적인 의견도 많이 나오는 편이라 이를 실천하는 기업들은 꽤 있지만 아직 주류가 된 적은 없다는 정도입니다.

TDD의 효용에 대해서는 흥미로운 토론이나 정량적 연구 결과도 꽤 발표된 내용이 많이 있기 때문에 관심이 있는 분들은 한 번 쯤 찾아보셔도 괜찮은 주제라고 생각합니다.

좋은 글입니다.

다만 유닛 테스트가 만병통치약은 아니죠.

소프트웨어 개발의 중요한 부분인건 분명하지만,

유닛 테스트 하기 어려운 경우도 가끔 튀어나오고, 그걸 설계상의 오류라고 치부 당하면,

당하는 사람은 좀 억울한 면도 있습니다.

그 개발의 목표와 TDD는 서로 타협해야 합니다.

성능이 지상과제처럼 중요한 경우, SW공학적 원칙이나 디자인 패턴을 깨고 나섰다 하더라도 잘한 일인 것 처럼요.

이글 본문을 요약하면 

내가 TDD를 적용하지 않는 것은 그것이 미친짓이라서 이고 당신들이 TDD를 적용하지 않는 것은 실력이 모자라서 인가요...

갠적으로 이렇게 주장하시는 분 옆에서 어떻게 일을 하는지 한번 보고나 싶긴 합니다.

제가 이런 생각을 하는 이유는 말이야 쉽지 직접 보면 TDD를 교과서적으로 언급하는 수준으로 작성해서 일하는 곳 못봤습니다.

일전에 아주 잠깐 스타트업에 그것도 외국계 스타트업에 있어본적이 있는데, 그래서 그런지 여긴 뭔가 다르구나 하면서 봤던게 TDD 개발 방법론으로 일을 한다는 거였지요.

스모크 테스트도 하고 스마트폰 UI 테스트는 돈주고 산 프로그램으로 자동화까지 해놓은 곳이였는데, TDD 를 한다고 해서 코드를 한번 봤더니 말이 좋아 TDD 지, 그냥 테스트 OK 만 나오도록 짜놓고 앉았고.. ㅋㅋ TDD 를 할라면 그 역할을 담당하는 클래스나 메소드가 하는 일에 대한 테스트를 진행해야 하는데, 이것이 결과 리턴값 체크만 하는 TDD 를 작성하는 업체 아주 많습니다. 리턴값이 맞는지만 초점을 맞춘다는 겁니다. assertEquals("abc",$abc); ㅋㅋㅋ 물론 많은 오픈소스 코드에도 결과 리턴값만 체크하는 경우도 종종 보곤하는데, 적당히 써먹어야지.. ㅋㅋ 리턴값이 맵인지 리스튼지 테스트하는게 TDD 인가 싶기도 하고..

TDD 를 할려면 테스트가 가능한 코드를 작성해야 하는데, "테스트가 가능한 코드" 를 짜기가 쉬워야 말이죠..조낸 어렵습니다.

ps, TDD 하기전에 코딩 스타일이나 좀 맞추던가... 문서하나 없어서 문서좀 달라니까 "소스에 다 들어있다" 하는 명언을 남겼던 회사... 지금 생각해도 소름돋네요..;;

본문에 TDD는 많은데 정작 TDD와 무슨 관계가 있는 글인지는 잘 모르겠네요;

TDD관련 내용 덧붙이고 갑니다. 참고하시길

1. 테스트 범위

작년 오키에서 주최한 TDD 세미나에서 나온 질문 중 이런 것이 있었습니다.

왜 TDD 하는 사람들은 모든 코드를 다 단위 테스트 하지 않으면 나쁘다고 말하느냐?

저는 당시 토론 사회를 맡았는데 패널 두 분과 저 세명은 같은 답을 했습니다.

누가 그러더냐? 우린 안그러는데?

=> Test everything that could possibly break. (XP) 가 원칙으로 알려져 있죠.

- You should test things that might break. If code is so simple that it can't possibly break, and you measure that the code in question doesn't actually break in practice, then you shouldn't write a test for it... XP explained, Kent Beck

- TDD's view of testing is pragmatic. In TDD, the tests are a mean to an end - the end being code in which we have great confidence. If our knowledge of the implementation gives us confidence even without a test, then we will not write that test. TDD by example, Kent Beck

- .. Not worth the investment? You've got to be kidding me! How could anyone NOT want that suite of tests? Do yourself a favor and stop quibbling over silliness. Uncle Bob

2. 설계에 자신이 없다면 TDD 하지 않는 것이 낫다?

그러니 설계에 자신이 없다면 TDD 하지 않는 것이 낫습니다. 반대로 설계 역량이 높을수록 TDD 비용은 줄어듭니다. 당장 설계 역량이 부족한데 TDD를 할 필요는 없습니다. 불필요한 시간 낭비 하지말로 수동 테스트 한 다음 남는 시간에 설계 공부하는 것이 현명합니다.

=> TDD 수행에 있어 설계 역량이 필요하다는 내용은 본적이 없습니다. 오히려 자신감이 없기에 TDD를 하라고 되어 있죠

- TDD는 더 깔끔한 설계를 할 수 있도록, 그리고 더 많은 것을 배워감에 따라 설계를 더 개선할 수 있도록, 적절한 때 적절한 문제에 집중할 수 있게끔 도와준다, TDD by example, Kent Beck

- 기능을 추가할 때 어떤 설계가 좋을지 고민하지 않고, 할 수 있는 한 가장 쉽게 테스트를 통과시키려고만 노력한다, 마틴 파울러

- Testing Improves Code. An example showing how writing some tests can help you to improve the code.

- 마이크로 레벨에서 TDD는 설계에 도움을 주지만 매크로 레벨에서 설계를 향상시키는 것은 별개란 내용도 어디선가 봤던 기억이 있네요

타키투스 

"갠적으로 이렇게 주장하시는 분 옆에서 어떻게 일을 하는지 한번 보고나 싶긴 합니다."

아래 글 참고하시면 도움이 되겠네요. 

https://gyuwon.github.io/blog/2019/07/22/tdd-in-real-world.html

sbroh 

글 참조가 아니라 직접 보고 싶다고 한것을 "글 참고" 하시면 되겠다니... 재귀적 메기기 인건가요? ㄷㄷ