전체 팀이 익숙해지면 TDD의 실제 오버 헤드는 무엇입니까?

TDD를 수행하는 데 소요되는 시간의 백분율은 얼마입니까?

프로젝트 수명주기 동안이 비율의 비용 및 보상 변경이 있다고 가정합니다.

초기 단계 에는 비용이 많이 들지만 보상은 거의 없다고 생각합니다 . 또한 ( 리팩토링 중 ) 테스트의 이점을 누릴 수 있습니다.

나는 당신의 시간의 30-50 %에서 단위 테스트를 쓰고 있다고 들었습니다 . 그러나 이러한 테스트를 작성하는 데 소요되는 시간 을 고려하지는 않습니다 .

이것에 대한 모든 사람들의 경험은 무엇입니까?

웨스

편집 시간과 시간은 얼마입니까? 버그 수정 및 리 팩토 빌리티?

나는 당신의 시간의 30-50 %가 단위 테스트를 쓰고 있다고 들었습니다. 그러나 그것은 절약 된 시간을 고려하지 않습니다

내 경험상 50 % 이상입니다.

테스트를 작성하면 솔루션이 매우 쉬운 경향이 있습니다. 따라서 테스트 작성 시간의 70 %-75 %를 소비하는 것이 이상하다고 생각하지 않지만 '제작 코드'(코드 테스트 중)를 작성하고 디버거에서 거의 시간을 소비하지 않는 시간이 훨씬 적습니다. .

버그를 빨리 발견할수록 더 저렴하게 해결할 수 있으며 TDD는 그 문제를 엄청나게 도와줍니다. 지난 2 개월 (8 개월 프로젝트 중)이 버그를 수정하는 데 사용 된 프로젝트에서 작업했으며 그 단계는 TDD로 거의 완전히 제거됩니다.

그래도 실제 가치는 유지 관리에 있습니다. 테스트를 통해 코드베이스를 상속하면 코드베이스를 변경하기가 두렵지 않습니다. 테스트를 통과해도 아무 것도 깨지 않은 것 같습니다. 변경을 두려워하지 않기 때문에 무언가가 옳지 않은 경우 리팩토링 할 수 있습니다. 즉, 코드를 깔끔하게 만들 수 있고 디자인이 더 적합하며 이론적으로 변경 사항을 적용 할 수 있습니다. 부두 코드를 사용하면 모든 사람들이 감동하기를 두려워합니다.

단위 테스트를 실행할 때마다 코드를 수동으로 테스트하는 데 걸리는 시간이 절약됩니다.

테스트 작성에 필요한 것으로 인용 한 시간의 30 % ~ 50 %는 더 나은 (테스트 가능한) 소프트웨어 디자인의 이점으로 인해 크게 상쇄됩니다.

테스트를 수동으로 수행하는 것보다 자동 테스트를 작성하는 데 4 배가 걸린다고 가정 해 봅시다. 즉, 네 번째로 자동화 된 테스트를 실행하면 비용을 지불하게됩니다. 그 후에 자동 테스트를 실행할 때마다 무료입니다.

테스트가 자동 단위 테스트인지 자동 기능 테스트인지에 관계없이 적용됩니다. 모든 기능 테스트를 자동화 할 수있는 것은 아니지만 많은 기능 테스트를 자동화 할 수 있습니다. 또한 자동화 된 테스트는 사람보다 신뢰할 수 있습니다. 매번 똑같은 방식으로 테스트를 실행합니다 .

단위 테스트가 있다는 것은 메소드의 기본 구현 (성능 또는 기타 이유로)을 리팩터링 할 수 있으며 단위 테스트는 메소드의 기능이 변경되지 않았 음을 확인합니다. 이는 단위 테스트 가 메소드의 기능성을 지정 하는 TDD의 경우에 특히 해당 됩니다.

TDD는 종종 시간과 비용이 아닌 코드 품질을 기준으로 측정됩니다. 그러나 코드 품질이 향상되면 개발자와 함께 작업하는 모든 사람이 더 잘 작업 할 수 있습니다 (소비 시간 감소, 비용 절감, 행복 등). http://davidlongstreet.wordpress.com/2009/04/29/new-software-metric-wtfs-per-minute/

작문 테스트는 기능적 요구 사항과 비 기능적 요구 사항의 검증을 자동화하는 데 도움이됩니다. TDD (실제로 BDD, 높은 수준의 TDD)를 채택하도록 설득 한 동영상 : http://video.google.com/videoplay?docid=8135690990081075324#

• 기능 테스트를 작성하면 개발 단계 초기에 버그 / 문제를 발견하는 데 도움이 될 수 있습니다 . 큰 코드 기반이 있다고 가정하십시오. 단위 테스트 / 사양 에서는 "모든 테스트 통과"/ "2 테스트 실패, 라인 xyz 참조"만 표시하면됩니다. 개발 및 테스트를 수행 할 개발자 팀만 있으면됩니다 . 단위 테스트 / 사양하지 않고 , 당신은 할 필요가 수동으로 비교 예상 문에 인쇄 된 진술을하고, 수동 / 클래스 버그가있는 방법 추적. 이를 위해서는 두 개의 별도 팀 (개발자와 테스터) 이 필요할 수 있습니다.

• 필기 테스트는 개발자가 진행 상황과 직면 한 문제를 설명하는 데 도움이됩니다.

• TDD는 코드의 유지 관리 성, 적응성 및 유연성을 충족시키는 데 도움이됩니다. 개발자가 작은 테스트 가능한 청크를 작성하고 더 큰 테스트 가능한 청크로 묶을 것을 권장합니다. 다른 방법으로 (리팩토링 실습의 일부) 우리가 견고한 테스트를 작성했다는 조건으로 작동합니다. 결과적으로 멋지게 작성된 모듈 식 코드를 가질 수 있습니다.

TDD를 통해 다음과 같은시기를 알게되어 기쁩니다.

• 고객이 요구 사항 변경 요청 (만족 요구 사항)
• 더 나은 코드 작성 방법 발견
• 팀원은 코드 개선을위한 제안을합니다
• 코드를 다른 사람들에게 설명 / 전달해야합니다

개발 프로세스가 작은 단계를 거치기 때문에 TDD는 지루할 수 있으므로 예측하기가 쉽습니다.

우리의 경우에는 40 %에 가까운 것으로 추정됩니다. 그러나 나는 우리가 이것보다 더한 단계를 거치지 않았다고 생각합니다. 우리는 개발자들에 의해 살해되는 코드 스켈레톤 과 마찬가지로 살해되는 테스트 스위트를 모두 뱉어내는 코드 생성기를 가지고 있습니다 . 대부분의 테스트 노력은 실제로 적절한 테스트 데이터를 추적 (또는 작성)하여 완벽한 적용 범위를 확보하는 것입니다.

중요한 장기 측정은 코드 품질 및 코드 신뢰성뿐만 아니라 무의미한 테스트를 수행하는 팀을 태우지 않는 것입니다.

단기 조치는 테스트 자동화의 ROI입니다

예를 들어 : 지난주에 내부 아키텍처 변경으로 인해 1000 개가 넘는 코드를 변경하고 자동화 된 테스트 스위트를 시작한 후 절전 모드로 전환했습니다.

테스트는 28 분이 걸렸다. 그들은 모두지나 갔다. 동일한 40 개 이상의 승인 테스트를 수동으로 수행하는 데 약 6 시간이 걸립니다.

또 다른 예 : 이전 반복에서 수동 테스트로는 찾지 못할 미묘한 버그로 테스트 시나리오 중 하나를 시작했습니다 (자동 테스트는 수동 테스터가 거의 수행하지 않는 db 무결성 검사를 수행합니다). 나는 그것을 알아 내고 고치기 전에 약 50 번 그 테스트 시나리오를 실행해야했습니다. 테스트 시나리오 작업을 수동으로 수행하는 데 약 50 분이 소요됩니다. 하루에 41.6 시간의 노동력이 절약 됩니다.

테스트를 몇 번이나 수행해야하는지 정확히 알 수 없기 때문에 자동 테스트의 ROI를 미리 계산할 방법이 없습니다.

그러나 나에게 자동화 테스트의 ROI는 거의 무한합니다

단위 테스트를 복잡한 알고리즘, 자동 생성 가능한 경우 및 회귀로 제한하는 데 많은 도움이 될 수 있습니다.

구성 요소 테스트는 종종 사소한 코드에 큰 도움이되며, 테스트는 인터페이스에만 연결되기 때문에 구현 변경이 훨씬 저렴합니다.

세분화 된 단위 테스트를 통한 전체 적용 범위는 구현을 변경하거나 리팩토링하는 데 엄청난 오버 헤드를 가져옵니다.