2008-10-06 4 views

답변

9

시간은 단위 테스트 시간과 기능 코드 시간 사이에 거의 같습니다.

어떤 사람들은 이것을보고 시간 낭비라고 말하지만, 앱을 실행하고 가능한 모든 경로 (단계)를 수행하는 유일한 옵션이 있다면 실제로 개발자 테스트에 소비하는 시간보다 적습니다. 물론 많은 개발자 테스트를 수행하지 않으면 QA에서 돌아온 버그를 수정하는 데 시간을 할애 할 수 있습니다.

어느 쪽이든 단위 테스트를 작성하는 데 실제로 프로젝트에 소요되는 시간을 절약 할 수 있습니다.

코드를 유지 보수해야하는 경우 (약간의 변경, 기능상의 작은 추가), 차이가있을 수 있습니다. 변경중인 코드가 이미 완전히 다루어지고 변경 사항이 테스트 변경을 필요로하지 않으면 시간은 0입니다. 그렇지 않으면 분명히 동일하지는 않습니다.

그러나 테스트 시간이 많이 절약됩니다. 코드의 나머지 부분을 다루는 테스트를 이미 만들었으므로 새로운 코드 나 앱을 사용하지 않고도 변경 사항에서 발생하는 우발적 인 변경 사항을 발견 할 수 있습니다.

6

나는 단위 테스트 코딩의 약 50 %를 소비한다고 말하고 싶습니다. 그것은 개인적인 경험에서 제외 이득의 측정하기 어렵습니다,하지만 난이 3 명 주요 혜택 제공 찾을 : 더 디자인에 대해 생각

  • 힘을, 당신은
  • 당신을 허용하는 결과로 더 나은 코드를 작성하는 경향이 당신이 두려워하지 않고 여러 달/년을 재조정/유지하기 위해 모든 것을 깨뜨릴 것입니다.
  • 단위 테스트에서 잡은 사소한 버그를 찾아 다니며 시간 낭비하지 않기 때문에 전체 프로젝트 시간이 단축됩니다
2

작업중인 코드에서 처음부터 무언가를 작성하고 테스트를 진행할 때는 테스트없이 기능을 구현하는 데 거의 같은 시간이 걸리지 만 발견되는 버그의 양은 오래 걸리지 않고 얼마나 쉽게 당신이 그 코드 기반을 유지하고 확장 할 수 있는가? 코드가 예상대로 작동하지 않고 디버거를 사용하여 현재 진행중인 작업을 훨씬 더 광범위하게 파악해야하는 어려운 작업을 피할 수 있으므로이 경우 테스트를 통해 작성하는 것이 더 빠르다고 주장 할 수 있습니다 TDD보다 일반적으로 허용되는 설정 변경.

기존 "기존"코드 기반 위에 기능을 구현하려는 경우 (Michael Feathers가 레거시를 정의 할 때와 같이) 테스트를 통해 기능을 구현하는 데는 상당 테스트를 작성하기 전에 반드시 수행해야하는 신중한 리팩토링이 일반적으로 가능합니다. 이 경우, 단위 테스트를 작성하는 것은 여전히 ​​장기적인 이점을 갖지만 장기적인 이익이 즉각적인 비용으로 정당화되는지 여부에 대한 추가 생각을해야합니다.

일반적으로 레거시 코드 기반에 대한 추가 비용에도 불구하고 단위 테스트 든 기능 테스트 든 자동 시험의 형태를 선호합니다. 그것 없이는 유지 보수가 매우 어려운 코드 기반에 빠질 가능성이 높으며 자주 반복되는 수동 기능 테스트가 필요합니다.

관련 문제