一旦整个团队都习惯了，TDD的真正开销是多少？

24

TDD可节省多少时间并计算成本。

我认为在项目生命周期中成本和报酬变化的百分比是多少。

我以为初始阶段的成本更高，但回报却很少。进一步（在重构期间），您将从测试中受益。

我听说您有30-50％的时间在编写单元测试。但是，这并未考虑编写这些测试所节省的时间。

大家对此有何经验？

韦斯

编辑节省了多少时间以及时间成本？在错误修复和重构中？

productivity tdd

— 韦斯
source

在编写代码之前编写测试或在编写代码之后编写测试，我认为无论编写测试的方式，开销都可以忽略不计。

— 克里斯，2010年

1

@Chris，当您首先编写测试时，您需要预先设计API，而不是事后才考虑。

1

另请参见programmers.stackexchange.com/questions/206/always-and-only-tdd

— 罗伯特·哈维

3

@Thorbjørn：同意您的看法，尽管完全可以在不使用TDD的情况下设计API，但这并不是事后才想到的。

— 罗伯特·哈维

2

@Steven：是的，我知道TDD是什么。您说预先设计API很有意思。这让我印象深刻。我从来没有完全接受过这样的想法，即您可以通过编写大量测试来“增长” API。

— 罗伯特·哈维

8

我听说您有30-50％的时间在编写单元测试。但是，这没有考虑节省的时间

根据我的经验，这个比例超过50％。

一旦编写了测试，解决方案就会变得非常容易。因此，我不认为花费70％-75％的时间来编写测试是很奇怪的，但是您花费的时间却少得多，而无需花费时间在调试器中编写“生产代码”（经过代码测试）。

您越早发现错误，修复起来越便宜，而TDD可以极大地帮助您解决问题。我从事的项目（过去8个月的项目中的最后2个月）用于修复错误，而使用TDD几乎可以完全消除该阶段。

对我而言，真正的价值在于维护。继承带有测试的代码库使您不必担心更改它。当测试仍然通过时，您觉得自己没有破坏任何东西。由于您不害怕进行更改，因此在某些不正确的地方您愿意进行重构。这意味着代码可以变得更简洁，设计可以更好地适应，并且在理论上可以进行更改。与伏都教密码相反，每个人都害怕碰触。

— 布拉德·库比（Brad Cupit）
source

如果测试是好的测试。但是，有些总比没有好。通常，您可以通过查看测试是否良好来快速分辨。

— Michael K 2010年

1

因此您认为可以节省时间。（2个月）根据您的示例，但要花多少时间进行测试？好答案顺便说一句。

— 韦斯

@Wes很难知道。我编写待测代码的速度更快，但是花了很多时间在测试上，这可以帮助我及早发现错误，从而节省了时间，但是我不知道节省了多少时间，因为我没有找到错误晚的！我个人认为TDD在短期内会花费更多，但从长期来看会节省更多。项目时间越长，受益越多。

— 布拉德·库皮

现在将其移至我认可的答案。

— Wes

15

每次运行单元测试时，您都节省了手动测试代码所需的时间。

您引用了编写测试所需的30％到50％的时间，这也被拥有更好（可测试）软件设计的好处所抵消。

假设编写自动化测试所需的时间是手动执行测试所需时间的四倍。这意味着您第四次运行自动化测试，这是值得的。此后每次您运行自动测试时，它都是免费的。

无论测试是自动化的单元测试还是自动化的功能测试，这都是正确的。并非所有功能测试都可以自动化，但其中许多功能可以自动化。另外，自动化测试比人更可靠；每次都会以完全相同的方式运行测试。

进行单元测试意味着您可以重构方法的基础实现（出于性能或其他原因），并且单元测试将验证该方法的功能未更改。对于TDD尤其如此，其中的单元测试指定了方法的功能。

— 罗伯特·哈维
source

我完全不相信您可以省去手动测试。TBH。为确保某些功能正常工作，至少就我所知，您仍应使用回归。

— 韦斯

6

单元测试是回归测试。我不确定你在说什么。

— 罗伯特·哈维

2

单元测试和功能测试都是回归测试的形式。我认为Wes是指后者。

— Phil Mander 2010年

@Phil Mander完全正确。@Robert Harvey我的意思是功能测试，我的大脑没有找到正确的词。虽然我很确定我的潜意识是在功能上使用了该词的，但还是不错的编辑。

— 韦斯

我不认为每次都以完全相同的方式运行测试实际上是肯定的，因为很可能会一直错过寻找类似问题的机会。

— 2011年

5

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可能很无聊，因为开发过程需要一些小步骤，因此变得可预测。

— n193853
source

4

就我们而言，我估计它接近40％。但是，我认为我们所经历的阶段不仅仅如此。我们有一个代码生成器，它吐出了开发人员充实的代码框架和同样充实的测试套件。实际上，我们的大部分测试工作都用于跟踪（或创建）适当的测试数据，以确保我们获得完整的覆盖范围。

— TMN
source

这是本地生成的代码生成器，还是在野外可用的开源代码生成器？

— 罗伯特·哈维

它是基于.NET CodeDOM类的手动解决方案。

— TMN 2010年

3

重要的长期措施不仅是代码质量和代码置信度，而且还应该使团队进行无意识的测试不致于疲倦

短期措施将是自动化测试的投资回报率

例如：上周，由于内部架构变更，我进行了1000多次代码更改，启动了自动化测试套件，然后入睡。

测试耗时28分钟；他们都通过了。手动执行相同的40多个验收测试大约需要6个小时。

另一个示例：在先前的迭代中，我用一种可能无法发现手动测试的细微错误（其中一种是自动测试执行了手动测试人员几乎从未执行过的数据库完整性检查）来弄乱了一个测试场景。在设法弄清楚并修复它之前，我不得不运行该测试方案大约50次。手动执行测试方案操作大约需要50分钟。这样一天就能节省41.6工时

您无法预先计算自动化测试的投资回报率，因为您无法确切知道运行测试所需的次数。

但是对我来说，自动化测试的投资回报率几乎是无限的

— 史蒂文·A·劳
source

1

哦，这很有趣。我认为数据库完整性检查应该在单元测试之外。除了单元测试之外，您还可以自动进行其他哪些测试？

— 韦斯

1

@Wes：TDD中的测试被称为“单元”测试，但是不要让这个不幸的名字限制它们的范围。他们的目的是测试功能。功能可能是“ foo函数始终返回null”，也可能是“最大负载下的整个系统延迟必须小于12皮秒”。

— Steven A. Lowe 2010年

0

将单元测试限制在复杂的算法，可以自动生成它们的情况以及回归方面，可以有很大帮助。

组件测试通常对于相当琐碎的代码来说都做得很好，而且更改实现要便宜得多，因为测试仅与接口耦合。

细粒度的单元测试的全面覆盖对于更改或重构实现具有巨大的开销，这正是他们声称使之简单的事情。

— 约曼
source