TDD /测试过多的开销/维护负担？

因此，您已经多次从不真正了解测试价值的人那里听到过。刚开始时，我是敏捷和测试的追随者...

我最近在讨论有关在产品重写上执行TDD的问题，其中当前团队不进行任何级别的单元测试，并且可能从未听说过依赖注入技术或测试模式/设计等（我们什至不会继续清理代码）。

现在，我对产品的重写负全部责任，并被告知，以TDD的方式进行尝试，只会使它成为维护的噩梦，并且对于团队维护来说是不可能的。此外，由于它是一个前端应用程序（不是基于Web的），因此添加测试是没有意义的，因为业务驱动力发生了变化（通过更改当然意味着有所改进），这些测试将过时，其他开发人员将来的项目将无法维护它们，并且将成为它们修复等方面的负担。

我可以理解，在目前没有任何测试经验的团队中，TDD听起来并不好，但是在这种情况下，我的观点是我可以向周围的人教我的实践，但更进一步，我知道TDD会让您变得更好软件。即使我要使用TDD来生产软件，并抛弃所有测试以将其交给维护团队，与从一开始就完全不使用TDD相比，这肯定是更好的方法吗？

我被提到在一个从未听说过的团队的大多数项目中执行TDD时被击落。“接口”的想法和外观奇特的DI构造函数使他们望而却步。

在尝试出售TDD的简短对话中，有人可以帮助我吗？在屈服于公司/团队之前，我通常会有一个简短的辩论窗口。

以TDD的方式尝试它，只会使它成为维护的噩梦，并且对于团队维护来说是不可能的。

你不能赢得那个论点。他们正在弥补。可悲的是，您也没有真实的事实。您提供的任何示例都会引起争议。

指出这一点的唯一方法是拥有维护成本较低的代码。

此外，由于它是一个前端应用程序（不是基于Web的），因此添加测试毫无意义，

每个人都这样说。也可能部分正确。如果应用程序设计合理，则前端几乎不会做任何事情。

但是，如果应用程序设计不良，则前端会做太多事情，并且很难进行测试。这是设计问题，而不是测试问题。

随着业务驱动力的变化（通过变化，它们当然意味着改进），测试将变得过时，将来参与该项目的其他开发人员将不会对其进行维护，而将成为他们修复的负担等。

这与上面的论点相同。

你不能赢得争论。所以不要争论。

“我对该产品的改写负全部责任”

在这种情况下，

1. 仍然添加测试。 但是，您可以逐步添加测试。不要花很长的时间先编写测试。转换一点。测试一点。转换多一点。再测试一点。

2. 使用这些测试，直到有人弄清楚测试是否有效并询问为什么情况如此顺利。

在重写（从C ++到Java）时，我有相同的论点，即使它们告诉我不要，我也只是使用了测试。

我发展很快。我要求提供正确结果的具体示例，然后将它们发送到电子表格中。我将电子表格转换为unittest.TestCase（不告诉它们），并使用它们进行测试。

在进行用户验收测试时-发现错误-我只是要求对带有示例的电子表格进行检查，更正和扩展，以涵盖在验收测试中发现的问题。我将更正后的电子表格转换为unittest.TestCase（不告诉它们）并使用它们进行测试。

没有人需要知道详细解释您是成功的。

只是成功。

您只能从实践的角度说服此类人员（如果有的话），以证明TDD在现实生活中的价值。例如，以一些最近的错误为例，并说明如何构建单元测试，以确保100％不会再次出现此错误。然后，当然要编写更多的单元测试，以防止出现整个类的类似错误（并且谁知道，也许甚至在发现代码中更多休眠的错误的途中）。

如果这在短期内不起作用，则您需要做更长的工作，只需执行TDD并根据自己的任务勤奋地编写单元测试即可。然后在半年左右的时间（如果您所在的环境中可能）编译一些简单的统计信息，以比较由不同开发人员完成的代码/任务中的错误率（进行匿名处理以防止疏远您的队友）。如果您可以指出，在代码中发现的错误比在其他代码中发现的错误要少得多，那么您可能很想将其出售给管理层和其他开发人员。

从理论上讲，TDD是一件好事，但您必须对此有所实际，但是除非您为添加的所有内容更新测试，否则其中的意义不大-没有人愿意运行报告损坏的测试未更新的测试代码！结果，这样做很容易导致成本太高-您将不是唯一处理该代码的开发人员。

客户有一个测试团队。好吧，将测试负担从开发人员转移到测试人员没有问题-毕竟这就是他们的工作，而且如果他们在测试中发现错误（也许他们有很多自动化测试工具），那么在您的级别编写单元测试毫无意义。找到这些错误将花费更长的时间，但是他们会发现那些您的测试不会执行的讨厌的“集成”错误。

这就是为什么他们不关心单元测试的原因。

最后，TDD是新事物，当我还是个小伙子时，我们从未进行过测试，并且编写了行之有效的代码。单元测试使某些人感到温暖和模糊，但这绝对不是正确代码的要求。

PS。我看到您的另一个问题，其中您批评抽象层，而在这里您批评缺少DI构造函数！做好决定 ：）

由于一切变化都像您所说的那样快，因此请向他们解释，它将用于回归测试。当有人引入新的错误时，这将省去很多麻烦，因为有人破坏了十年前编写的代码行，以解决特定功能的每10,000,000次执行中只有1次执行时发生的问题（仅当系统时钟打开时才会调用）客户端与服务器系统时钟的时差大于3分钟。只需问问他们，由于错误的软件，他们可以承受多少客户损失。

指出在开发过程中发现错误的成本为X，在测试过程中的成本为10X，在部署过程中的成本为X。查看它们是否至少允许您在特定模块中实施TDD的情况下进行试点测试，然后在开发，测试，部署和支持其他模块时跟进与其他模块的比较。给定足够的数据，您应该能够证明在TDD模块中使用更少的精力来生成代码。祝好运。

是的，维护测试是一种负担。更新它们，更新测试数据：所有这些都浪费了您的时间。

替代方法-手动测试事物，修复退化的bug，无法在几秒钟内告诉您代码有效-花费更多。

好的测试是负担，但它是携带的好负担。最好预先进行一些工作，这样可以在出现生产问题或迁移期间节省大量时间。即使负担很小，我也总是要进行测试，但我想承担这个负担。