寻找有关TDD如何改善质量和/或开发速度的案例研究[关闭]

在我的公司中，我正在努力说明为什么我们应该进行TDD。当前，大多数开发人员会尽其所能完成项目，然后在事实发生后添加单元测试，以满足经理的要求。来自开展TDD并看到收益的知名公司的任何示例将不胜感激。

对IBM和Microsoft中的4个项目的研究。发表在《Emperical Software Engineering》杂志上。

实证研究表明，测试驱动的开发可以提高质量

最早发表在《经验软件工程》杂志上的一篇论文报道：“ TDD似乎适用于各个领域，并且可以在不显着降低开发团队工作效率的情况下显着降低已开发软件的缺陷密度。” 该研究比较了Microsoft和IBM的4个使用TDD的项目与不使用TDD的类似项目...

本文包括IBM的1个案例研究和Microsoft的3个案例研究。每个案例研究都比较了两个团队，在相同的高级经理下使用相同的开发语言和技术开发相同产品的团队，其中只有一个团队使用测试驱动开发（TDD）。没有一个团队知道在开发周期中他们将成为研究的一部分。IBM案例研究跟踪了进行设备驱动程序开发的团队。在Microsoft案件之后，团队在Windows，MSN和Visual Studio上工作。

本文描述了团队在分钟到分钟的工作流以及任务级工作流中使用的TDD做法...

在最近的一本书“制造软件：有效的方法以及为什么我们相信它”中，有一章关于TDD的案例研究。但是您可能会感到失望，因为如果我没记错的话，该研究并未发现TDD的任何真正好处。无论如何，该案例研究都很有趣，并且该书通常是我最近阅读过的最好的软件书之一。它包含许多案例研究，例如结对编程，代码审查等。

绝对可以检查一下：TDD证明有效！还是？

...当菲尔·哈克（Phil Haack）宣布研究支持TDD的有效性时，我对查看链接的报告实际包含的内容有点兴趣。菲尔引用了摘要。

我们发现，考试优先的学生平均会写更多的测试，反过来，写更多的测试的学生往往会更有效率。我们还观察到，最低质量随程序员测试次数的增加而线性增加，与所采用的开发策略无关。

菲尔显然已经阅读了报告的其余部分，并提供了他喜欢的作品，这些作品似乎与标题一样。但是，当我看到支持最新和最佳软件开发实践的事物时，我担心的事情之一就是强烈倾向于确认偏差 -寻找当前理论的确认并忽略了反指示。

因此，作为一种好奇的类型，由于TDD是我一直在关注的东西，因此我有一天要看一下它是否适合我自己使用，因此我进入了报告...

...毫无疑问，测试首先导致每个功能单元进行更多测试。问题是这是否有价值。这项研究似乎表明可能并非如此，至少如果质量是您的预期收益。但是然后，对于测试数量与质量不符，我并不感到惊讶，就像我对代码行数与生产力不符时并不感到惊讶。

作者对于TDD并不是那么有效有很多好处（尽管被大肆宣扬，尽管如此）

查看您和客户花费了多少时间手动测试软件；将其与估计需要多长时间的TDD型自动测试进行比较。口袋里的差异

以我的经验，TDD的自动测试是金牌，因为它们可以提供保险并消除大量的手动测试

正如Andres F所指出的那样，您只能从自动化测试中获得这些好处，而不一定是TDD-但是，TDD 需要自动化测试，而不是事后才想到或很不错

被迫首先考虑测试也迫使您在开始编写代码之前考虑与质量相关的问题，例如模块化，接口设计等。

我个人认为，TDD的最大好处之一是，编写测试首先可以使您在编写代码时就清楚代码实际上必须做什么的规范，而不是花一些时间弄清楚它。 -按您的代码。

您要为此提供理由：建议您在下一个项目中进行操作，然后从中学习。如果事实证明它对您而言非常有用，那么我希望您继续使用它，并且如果花费更长的时间来完成项目和/或花费所有时间编写测试而不是编写代码，那么您一定会将其转储为失败。

我认为，现实世界中的解决方案（就像大多数事物一样）是中途的，您需要测试，但是您不希望测试比项目更重要。

（我个人认为TDD是一种时尚，在理论上听起来不错，但是在实践中……不太好。我发现集成测试更为重要，但这可能只是我从事的复杂项目的类型）。

我使用TDD已有2年的时间了，当时我在哪里工作，我们都不愿意使用，包括管理人员。但是很快就变成了正确的做法。我们很快注意到的好处是

• 尽早发现错误。
• 没有意识到就编写更好的代码。
• 您的代码现在更加可维护，因为您的测试全部都是小块的（我们的功能是300-400行）。现在最多30个，并且全部经过独立测试。

经理们不会知道，因为他们都对一件事“您完成了”感兴趣。但是随后他们抱怨软件无法实现而不断崩溃。良好的覆盖范围和合理的测试。当有人破坏功能时，您真正看到的不是数量而是质量。同样不幸的是，如果您独自一人也很困难。我遇到了同样的问题，因为您可能需要更改代码（例如基类等），以便可以对软件的某些部分进行测试。

我举一个例子。我想模拟存储库，但是没有接口，我需要将存储库注入到我的服务层中，因此在整个商店中都添加/修改了构造函数，事实证明这很重要，但是在最终，我仅对系统的一个区域进行了200多次测试，就给他们留下了深刻的印象。

我通常会执行以下操作：

• 我的单元测试时间很短
• 只有1个断言。没有俄罗斯轮盘赌。
• 我测试了积极的消极和例外情况

关于案例研究，我不确定，我不确定是否见过。您需要构建自己的项目并成为案例研究，它们也会给您留下深刻的印象。

希望对您有所帮助