일반적으로 새로운 기능이나 버그 수정을 위해 단위 테스트를 작성하는 데 얼마나 걸립니까?

새로운 기능을 구현하거나 버그를 수정해야 할 때 일반적으로 테스트로 상황을 재현하려고합니다. 나는 언젠가 비품을 준비하고 테스트를 작성하는 데 약 3 시간을 소비합니다. 실제 기능 구현 또는 버그 수정에는 1 시간 미만이 소요됩니다.

다른 사람이 실제로 기능을 구현하거나 버그를 수정하는 것과 비교하여 테스트를 작성하는 데 최소 3 배 이상을 소비합니까? 테스트 작성 시간과 코드 작성 시간의 허용 가능한 비율은 얼마입니까?

버그 나 기능의 복잡성에 따라 다릅니다. 한 번 1.5 주 개발 기간 추정치와 3 개월 테스트 추정치가있는 프로젝트 하나를 기억합니다. 코드 변경은 작았으며 여기 저기 몇 줄이 있었지만 여러 가지 방식으로 보험 시스템의 여러 구성 요소에 영향을 미쳤으므로 매우 철저히 테스트해야했습니다. 또 다른 시간에 잘못된 장소에 괄호가 포함 된 버그가있었습니다. 그것을 찾기 위해 2 시간이 걸렸고, 그것을 고치려면 2 초가 걸렸지 만, 논리의 변화에 ​​영향을받은 수십 가지 시나리오를 테스트하는 데 약 일주일이 걸렸습니다.

일반적으로 정확한 코딩 방법이 없기 때문에 코딩에 소요되는 시간과 테스트에 소요되는 시간의 비율에 대해 걱정하지 않습니다. 일부 프로젝트에서는 일반적으로 프로젝트에 대해 표준이지만 프로젝트 후에도 변경 될 수있는 프로젝트 상대 비율이 나타납니다.

코드가 제대로 작동한다는 확신 을 가지고 필요한만큼 시간을 보내십시오 .

기능이 의도 한대로 작동하거나 버그가 올바르게 수정되었다는 것을 보여줄 때까지 테스트 작성에 충분한 시간을 보내십시오.

모든 상황은 다를 것입니다. 어떤 종류의 비율이있을 수 없습니다. 일부 테스트는 구현 시간의 10 분의 1이 걸리고 다른 테스트는 수백 배의 시간이 걸립니다.

한 번 프로젝트에서 단위 테스트를 도입 한 후 서바이벌을했습니다. 결과 : 테스트 작성에 소요 된 시간은 다시 구현하는 데 소요 된 시간보다 약 40 % 정도였습니다. 그러나 우리는 거기에 완전한 적용 범위를 목표로하지 않았으며 강력한 구조와 규칙을 가진 잘 확립 된 프로젝트였습니다.

타임 코딩 대 타임 라이팅 단위 테스트는 대략 동일해야한다고 말하고 싶습니다. 어쩌면 조금 더 가끔 SO 와 코딩에 소요되는 시간의 비율에 대한이 기사를 살펴보십시오.

당신은 올바르게 세고 있습니까? 테스트에 소요되는 시간을 정확하게 계산하려면 테스트없이 코드를 작성해야합니다.

테스트를 작성하는 데 실제로 3 시간이 걸리고 통과하는 데 코드를 작성하는 데 3 시간이 걸린 경우 테스트를 작성하지 않고 동일한 버그를 수정하는 데 5 시간 이상이 소요될 수 있습니다.

예, 실제 수정 코드보다 테스트에 훨씬 더 많은 시간을 보냅니다.