Joel의 테스트에서 테스트 중심 개발이 누락 된 이유는 무엇입니까?

Joel Spolsky가이 블로그를 읽고 더 나은 코드 작성을위한 12 단계를 수행했습니다 . 테스트 주도 개발 의 부재는 정말 놀랐습니다. 그래서 나는 질문을 Gurus에게 던지고 싶다. TDD가 실제로 노력할 가치가 있습니까?

Joel이 그 글을 쓴 지 2 년 후인 2002 년 Kent Beck의 책 이 나오기 전에 테스트 주도 개발은 거의 알려지지 않았습니다 . 그러면 Joel은 왜 테스트를 업데이트하지 않았습니까? 아니면 2000 년에 TDD가 더 잘 알려졌다면 그의 기준에 포함 시켰습니까?

중요한 이유는 그 프로세스의 특정 세부 사항이 아니라 잘 정의 된 프로세스를 가지고 있다는 단순한 이유 때문입니다. 그가 특정 버전 제어 시스템을 지정하지 않고 버전 제어를 권장하거나 특정 브랜드를 권장하지 않고 버그 데이터베이스를 권장하는 것과 같은 이유입니다. 좋은 팀은 지속적으로 개선하고 적응하며 특정 상황에서 특정 상황에 적합한 도구와 프로세스를 사용합니다. 일부 팀의 경우 TDD를 의미합니다. 다른 팀에게는 그렇게 많지 않습니다. TDD를 채택하는 경우 화물 운송 사고가 아닌지 확인하십시오 .

Joel은 실제로 몇 곳에서 구체적으로이 문제를 해결했습니다.

그는 테스트가 많은 중요한 문제, 특히 "이 소프트웨어의 사용자 인터페이스가 빨라?"와 같은 주관적인 문제를 포착 할 수 없다고 설명했습니다. 그에 따르면, Microsoft의 자동화 된 테스트에 대한 의존은 Windows Vista를 끝내는 방법입니다.

그는 자신의 경험에서 실제로 사용자가 발견하는 버그의 종류가 두 가지 범주로 분류되는 경향이 있음을 작성했습니다. 1) 일반적인 사용법으로 표시되는 버그. , 또는 2) 엣지 케이스는 너무 모호하므로 아무도 테스트를 작성하기 위해 테스트를 작성하려고 생각하지 않았을 것입니다. 그는 FogBugz에서 자신과 그의 팀이 고친 버그 중 아주 적은 비율 만이 단위 테스트에서 잡히는 일종의 것이라고 언급했습니다. (지금은 해당 기사를 찾을 수 없지만, 내가 의미하는 것을 아는 사람이 있으면 여기 링크를 자유롭게 편집하십시오.)

그리고 그는 프로젝트가 많은 단위 테스트를 통해 매우 큰 프로젝트로 성장한 다음 의도적으로 무언가를 변경하고 매우 많은 수의 깨진 단위 테스트로 끝나는 경우 가치보다 문제가 될 수있는 방법을 썼습니다 . 그는 사람들이 자신이해야한다고 제안 할 때조차도 단위 테스트가 야기 할 수있는 문제를 Joel 테스트의 13 번째 포인트로 추가하지 않은 이유를 사용합니다.

Joel Spolsky 자신 은 2009 년에이 질문에 다시 답변했습니다 .

Joel : Test Driven Development에 대한 논쟁이 있습니다 ... 모든 것에 대해 단위 테스트를해야하는지, 그런 종류의 것들 ... Joel Test를 읽은 후 많은 사람들이 저에게 쓴 "13 일이 있어야합니다. 여기에있는 것 : 단위 테스트, 모든 코드의 100 % 단위 테스트. "

그리고 그것은 당신이 필요하지 않은 것에 대해 약간의 교리 학자라는 사실을 깨닫게합니다. 마찬가지로 민첩한 프로그래밍의 전체 아이디어는 필요한 작업을 수행하는 것이 아니라 필요에 따라 페이지 오류를 일으키는 것입니다. 나는 모든 것을 자동으로 테스트하는 것이 많은 도움이되지 않는다고 생각합니다. 다시 말해, 코드가 실제로 작동하는지 확인하기 위해 엄청나게 많은 단위 테스트를 작성하고 작동하지 않는지 확실히 알 수 있습니다. 테스트를 작성하십시오] 실제로 작동하지만 ... 잘 모르겠습니다. 나는 그것을 잘 표현하지 못하기 때문에 화염 우편물을 얻을 것입니다. 그러나 팀이 실제로 단위 테스트의 100 % 코드 범위를 가졌다면 몇 가지 문제가 있다고 생각합니다. 하나, 그들은 단위 테스트를 작성하는 데 많은 시간을 소비했을 것이며, 그 시간 동안 품질을 향상시킬 수는 없었습니다. 내 말은, 그들은 품질이 약간 향상되었을 것이고, 코드를 변경하지 않고 아무 것도 깨지지 않는다는 확신을 가지고 코드에서 사물을 바꿀 수있는 능력이있을 것입니다.

그러나 내가 발견 한 단위 테스트의 실제 문제는 코드가 발전함에 따라 변경되는 유형이 단위 테스트의 일정한 비율을 위반하는 경향이 있다는 것입니다. 때로는 코드를 변경하여 단위 테스트의 10 %를 중단하는 경우가 있습니다. 의도적으로 당신이 무언가의 디자인을 변경했기 때문에 ... 당신은 메뉴를 옮겼습니다. 이제 그 메뉴에 의존하는 모든 것이 ... 다른 곳에 있습니다. 이제 모든 테스트가 중단됩니다. 또한 코드의 새로운 현실을 반영하기 위해 해당 테스트를 시작하고 다시 생성 할 수 있어야합니다.

최종 결과는 프로젝트가 점점 커질수록 단위 테스트가 많은 경우 해당 단위 테스트를 유지하고 최신 상태를 유지하고 유지하는 데 필요한 투자 금액입니다. 그것들이지나 가면, 당신이 그들로부터 얻는 혜택의 양에 비례하지 않게됩니다.

Joel 외에는 아무도 대답 할 수 없었습니다. 그러나 몇 가지 이유 / 관찰을 시도 할 수 있습니다.

우선, 테스트는 Joel의 테스트에서 빠지지 않습니다.

• 테스트는 12 단계로 직접 두 번 언급됩니다 (10 및 12).
• 빌드의 존재는 첫 번째 포인트 중 하나입니다. 빌드하는 아이디어는 용량이 깨 졌는지 확인하는 것이므로 테스트에 대해 이야기하고 있습니다.

둘째, Joel Test의 전체 아이디어는 (내가 이해하는 바와 같이) 빠르고 예 아니오 질문을하는 것입니다. "TDD를합니까?" 에 정확히 맞지 않을 것입니다 (답은 "우리 중 일부", "코드의 해당 부분"또는 "우리는 단위 테스트를 수행 할 수 있습니다").

세번째로, 나는 (시간조차 가치가있는 유일한 사람) (그런데 "프로그램을합니까?"가 아닌) 지점에 대해서는 아무도 말하지 않았다고 생각합니다. 미래의 팀원이든 고객이든 소프트웨어 팀과의 접촉-이것은 내 주변의 비 기술적 인 사람들에게 자신의 IT 부서가 얼마나 좋고 나쁜지에 대한 단서를 찾고자하는 목록입니다. 모든 것이 아니라 3 분만에이기는 것은 정말 좋지 않습니다.