我正在寻找可能在常规编码与编码+单元测试的时差之间进行研究（目前还不是严格的TDD）。我知道整个“从长远来看节省你的时间”的角度，但从项目规划的角度来看，对于之前从未做过的团队，我需要能够粗略估计分配多少额外时间。
这样的研究是否存在？任何人都可以从经验中评论吗？
答案 0 :(得分：17)
我知道您还没有兴趣购买完整的TDD，但我认为最佳性能和规划标记将在测试驱动开发案例研究中找到，例如Microsoft和IBM都会进行的研究。
进行了三个案例研究 微软的开发团队和一个 在采用TDD的IBM。该 案例研究结果表明 即释放前的缺陷密度 四种产品之间减少了 相对于类似的40％和90％ 没有使用TDD的项目 实践。主观上，团队 经历了15-35％的增长 最初的开发时间 采用TDD。 Source.
这是使用单元测试作为核心原则对正常开发与开发进行全面比较的前言的一部分。我们使用的前期开发计划添加量为20％，包括单元测试和集成测试。在所有诚实测试中，对于任何成功的软件都至关重要，单元测试只会消除一些硬码和手动操作。在完成一些功能并能够在几秒钟内测试系统后运行几百个单元和集成测试的能力是非常宝贵的。
人们在估算中添加了许多不同的“魔术”数字，以便将额外的时间用于编写单元测试，但实际上这只是简单的权衡。基本上，您可以平衡开发时间的增加与错误修复/错误检查时间的增加，同时还要考虑停机时间和系统关键性的相似性（如果它是主要收入或非必要系统）。
如果您对阅读here感兴趣，请参阅完整的Microsoft研究报告。它很短，但提供了一些有趣的发现。如果你非常热衷here是一个单元测试幻灯片，它以合理的细节概述概念和好处（以前这是这个演示文稿的源内容的链接，但遗憾的是内容现在已经消失了。） / p>
答案 1 :(得分：4)
在所有情况下，所有团队都应该是对的：
TimeOf(Coding+Testing) < TimeOf(CodingWithoutTesting)
根本不需要额外的时间。或者它会变得无用。
答案 2 :(得分：2)
我不能对这个主题的研究发表评论。
根据经验，我会说你的幻数范围是30-40％，因为你的团队是新手。您的团队需要学习如何创建模拟和假货，并习惯于编写测试，除了设置基础架构，大量的前期成本，直到您的团队加快速度。如果你的主要语言是C ++，那么编写模拟和伪造需要花费更多精力，而不是使用C＃（根据我的经验）。如果您的项目是全新的代码，那么与使用现有代码相比，它将花费更少的精力。如果你能让你的团队快速加快测试速度，那么TDD将比事后编写测试更省力。凭借足够的经验，测试时间可能约为20％，这是另一个神奇的数字。请原谅我缺少确切的数字，根据我的经验，我没有准确的指标。
答案 3 :(得分：2)
作为目前正在使用单元测试（不是完整的TDD，但接近完成）的第一个项目的人，我会说你应该将你的团队通常需要的时间加倍。< / p> Roy Osherove的书The Art of Unit Testing进行了一项非正式的研究，显示了这一点，但也表明当包含QA循环时，使用单元测试时整体释放时间略低，而且缺陷少得多。使用单元测试开发的代码。
我会提出这些建议：
让程序员阅读他们可以获得的关于单元测试和TDD的所有内容，尤其是他们可以找到的关于如何设计测试友好的代码（使用依赖注入，接口等）的任何内容。 Osherove的书将是一个很好的开始。
开始评估单元测试框架（NUnit，xUnit等）和Mocking框架（Rhino Mocks，Moq等），让他们选择标准化的框架。最受欢迎的可能是NUnit和Rhino Mocks，但我选择了xUnit和Moq。
不要让程序员放弃。改变你的心态并克服对变化的自然抵制可能很难，但他们需要努力解决这个问题。最初它可能感觉单元测试只是妨碍了，但是第一次他们动态重构代码部分并使用单元测试知道他们没有破坏任何东西而不是希望他们不会是一个启示。
最后，如果可能的话，不要在截止日期紧张的大型高压项目上开始单元测试;这可能会导致他们不能克服他们最初的困难并放弃单元测试而转而完成代码。
希望这有帮助！
答案 4 :(得分：2)
我需要能够粗略估计分配多少额外时间。
那太傻了。没有额外的时间。
这是你做的。采用现有的测试预算。项目结束时40％的开发工作。
在项目的整个生命周期中将大部分测试工作作为单元测试。称之为总工作量的30％，分配到各处。
最后将一些测试工作留给“集成”和“性能”测试。称之为总工作量的10％，仅在最后分配，仅用于集成和性能测试。或用户验收测试或任何未进行单元测试的遗留问题。
没有“额外”。无论如何你必须进行测试。您可以在项目期间将其作为一流软件，也可以在项目结束时做坏事。
TDD的“成本” - 充其量 - 是一种主观印象。仔细阅读优秀的研究摘要。 “主观，采用TDD后，团队的初始开发时间增加了15-35％”。 [重点补充。]
实际上TDD的成本为零。 TDD只是节省时间。
使用TDD比以其他方式创建软件要便宜得多。
为什么？
无论如何你必须进行测试。由于您必须进行测试，因此您可以通过围绕测试推动所有开发来规划测试。
如果您的测试用例不完整，那么您将拥有一组专注的任务。当您被电话，会议，产品演示，支持以前版本的操作呼叫打断时，很容易分心。当您的测试失败时，您会立即获得焦点。
无论如何你必须进行测试。它可以是Code然后是Test，也可以是Test，然后是Code。你无法逃避测试的成本。因为你无法逃脱，所以先做。
TDD具有“额外”或“增量”成本的想法是疯狂的。即使像http://www.springerlink.com/content/q91566748q234325/这样记录良好的研究也不能 - 实际上 - 比较两种方式的相同的项目。 “额外开发时间”的想法实际上无法衡量。这就是为什么它是一种“主观印象”。他们完全错了。
当你问程序员 - 他们是TDD的新手 - 如果TDD减慢了他们的速度，他们会对此撒谎。
是。他们说谎。
一。你让他们改变了。变化很糟糕。每个人都知道。他们不能说这更容易，因为它“不同”。
两个。它使管理层受到质疑。我们不能说我们的经理不好，这很糟糕。每个人都知道。他们不能说这更容易，因为我们的经理要求的先前事情现在显然是错误的。
三。大多数程序员（和经理）认为“真实”代码和“测试”代码之间存在区别。 TDD需要更长时间才能获得“真实”代码，因为您需要花费前期时间来执行“测试”代码。
这种“真正的”代码与“测试”代码是错误的区别。任何说这个的人都没有得到测试的重要性。由于测试对于演示应用程序的工作至关重要，因此测试代码应该是一流的。做出这种区分是错误的。测试代码是实际代码。
编写测试代码所花费的时间 - 实际上是 - 从实际代码的设计中抽出时间。您不是创建“纸张”设计，而是以测试用例的形式创建一个工作，生动的设计。
TDD可以节省时间。
否则他们反对改变和/或试图保护管理不会出现错误和/或在实际代码和测试代码之间进行错误区分。一切都是错误的。
答案 5 :(得分：0)
我不会依赖某项研究告诉你，你可以自己解决这个问题。
通常，开发人员会将主要功能分解为较小的任务，然后他们会估算每项任务的时间。作为此任务细分的一部分，他们还可以评估哪些任务（或多个功能）是可单元测试的，然后在那时他们还可以记录任务和估计以编写这些特定测试。单元测试的esitimates应该与他们测试的代码具有相同的误差范围 - 测试代码越复杂，测试越复杂（因此编写测试的估计越有可能超过计划）
当然这一切都不是一个完美的科学，如果它不需要项目经理:)如果你只是在寻找高水平的估计，那么你为单元测试部分提供的任何数字都将是与您为实际代码提供的数字一样不精确。在将其分解为任务之前，您将不会有任何确定性或准确性，然后对其应用相关的比例（就像您需要考虑开发人员的真正编码速度，可能只有60％-70％）。