우선 선결제 비용은 생각보다 높지 않습니다 . 예, 테스트를하지 않는 것보다 테스트에 더 많은 시간을 할애합니다. 그러나 "테스트 후"방법을 사용하면 실제로 무엇을 낭비하고 있습니까? TDD에는 10 시간이 걸리고 DDT에는 6 시간이 걸립니다. "추가"선결제 비용은 4 시간입니다. 이제 90 % 적용 범위와 같은 코드 메트릭 또는 요구 사항을 적용하면 TDD 및 DDT가 훨씬 더 비용이 많이 듭니다.
TDD로 버그가 적은 코드를 작성합니다. 테스트 요구 사항을 설명했기 때문에 하루 종일 코드가 원하는 작업을 정확하게 수행하고 있음을 증명할 수 있습니다. 아마도 당신은 그것이 잘못된 일을하기를 원했지만 변경 요청 인 버그는 아닙니다. 이것은 중요합니다. 작동하는 제품을 "판매"하는 것이 더 쉽지만 다르게 작동하거나 더 잘 작동 할 수 있으며 작동하지 않는 것으로 인식되는 제품을 판매하는 것입니다. TDD를 사용하면 테스트를 통과하고 작동하지 않는 코드를 작성하는 것이 사실상 불가능합니다. 요구 사항을 이해하지 못하고 잘못되었지만 작동하는 코드를 작성했을 수 있습니다.
코드 기반이 오래 될수록 TDD가 더 좋습니다. 테스트 스위트가 없거나 제대로 구현되지 않은 리팩토링을 시도하십시오. 간단한 변경만으로도 버그가 발생할 수 있습니다. 적용 범위가 좋은 테스트 스위트를 사용하면 제품이 진화함에 따라 제품이 계속 정상적으로 작동 할 수 있습니다. 또한 장기적으로 발생하는 상충되는 비즈니스 규칙을 강조하는 데 도움이됩니다.
당신은 그것이 작동하지 않는 것을 모른다. 테스트 스위트가 없으면 코드가 생각한대로 작동하는지 또는 작동하는 것처럼 보이는지 알 수 없습니다.
var foo = function(in) {
if(in == 0) {
return true
}
}
이제 응용 프로그램 전체에 전화 if(foo()){ doStuff() }하십시오. foo를 수정하면 어떻게됩니까?
var foo = function(in) {
if(in === 0) {
return true
}
}
테스트를 리팩토링하고 건조 해야합니다. 좋은 테스트 스위트는 유지하기 어렵지 않습니다. 잘 쓰여진 원자력 테스트를 통해 한 번에 1-2 개 이상 변경하지 않아도됩니다. 테스트 스위트에 더 큰 변화가 있었을 때, 뭔가 잘못되었다는 것은 큰 위험입니다.
나는 내 모든 방법을 알아야하고 코드가있을 때까지 어떻게 작동하는지 알지 못합니다.
글쎄, 당신은하지 않아야합니다. 일부 작업 단위가 완료되었는지 테스트하는 테스트를 작성해야합니다. 알 수없는 것을 테스트하고 있다고 생각되면 너무 크게 생각하거나 테스트가 너무 작습니다.
예를 들어, 문이 닫히고 잠겨 있다는 것을 알아야합니다. door.close () 및 door.lock ()을 테스트하고 문이 잠겨 있으면 door.open ()이 false를 반환합니다. 그게 다야. 테스트가 door.lock () 인 경우 데이터베이스에서 플래그를 설정합니다. 그런 다음 테스트가 너무 작습니다. 테스트는 door.lock ()의 작동 방식을 알 필요가 없습니다.
이제 문과 창문이 잠겨 있으면 house.isSecure ()는 true를 반환하는 테스트를 작성하고 있습니다. 문이나 창문을 먼저 보지 않으면 너무 큰 생각입니다.
마지막으로, 당신은 너무 큰 작업 단위를보고있을 수 있습니다 . 요구 사항 목록을 받으면 가장 작은 단위로 작업 할 수 있도록 요구 사항을 구성해야합니다. 해당 장치에 대한 테스트를 작성한 다음 코드를 작성하고 헹구고 반복하십시오.
본질적으로, TDD의 작동 방식에 대한 이해 (목록)는 벗어났습니다. 2/100 통과해서는 안됩니다. 1/1 통과, 2/2 통과, 3/3 통과, 4/4 통과 등이 있어야합니다.
당신을 위해 수정 된 목록
- 모든 사양을 얻으십시오
- 하나의 사양을 선택하십시오
- 그것을 테스트
- 그것을 코딩
- 그것을 테스트
- 테스트가 7로 넘어 가면 4로 넘어갑니다.
- 모든 스펙을 다 수행했다면 8로 가십시오. 그렇지 않으면 2로 가십시오.
- 소비자와 함께 사양을 검토하고 필요한 경우 새 사양을 추가하십시오. 올바르게 수행하면 테스트를 전혀 변경할 필요가 없습니다. 새로운 것을 추가하십시오. 요구 사항 수집이 분리 될 수 있으며 이전 테스트와 충돌하는 테스트를 추가해야하지만 테스트를 거의 변경하지 않아도됩니다.