编码与单元测试所花费的时间比率

Question

对编码单元测试的典型估计是什么，给出了对新功能进行编码的估算？对于维护代码的估算，这是不同的吗？

Answer 1

我的时间大约相当于单位测试的时间和功能代码的时间。

有些人会看这个，并说这是浪费时间，但如果你唯一的另一个选择是运行应用程序并逐步完成应用程序可以采取的所有可能路径，那么实际上花在单元测试上的时间就是少花在开发人员测试上的时间。当然，如果你没有进行太多的开发人员测试，那么你将花时间修复从QA返回的错误。

无论哪种方式，编写单元测试所花费的时间实际上都会节省我在项目上花费的时间。

当需要维护代码时（稍微改动，功能上的少量添加），可能会有所不同。如果更改的代码已经完全覆盖，并且您的更改不需要更改测试，那么您的时间为0.否则显然它不是，可能再次接近相等。

但是，你在测试时间上节省的时间要多得多;您已经创建了测试以涵盖其余代码，因此您可以在没有任何新代码或使用应用程序的情况下发现更改产生的任何意外更改。

Answer 2

我说我花了大约50％的时间编码单元测试。除了个人经验之外，很难衡量它的收益，但我发现它提供了三个主要好处：

• 迫使您更多地考虑您的设计，因此您倾向于编写更好的代码
• 允许你重新考虑/维持许多个月/年的生命而不会害怕你会破坏一切
• 减少了整个项目花费的时间，因为你没有浪费时间去寻找单元测试会抓到的琐碎错误

Answer 3

我发现它根据您使用的代码而变化很大 - 从头开始​​编写代码时，测试驱动，实现该功能可能需要大约相同的时间而不进行测试，但是您可以节省更长的时间关于将要找到的错误数量，以及维护和扩展该代码库的容易程度。有人可能认为在这种情况下用测试编写更快，因为你避免那些令人头疼的时刻，代码只是没有按预期运行，你必须使用调试器来发现正在发生的事情，而不是更宽比TDD通常允许的变更集。

当您尝试在现有的“遗留”代码库之上实现功能时（正如Michael Feathers将定义遗留代码），由于需要小心谨慎，因此通过测试实现该功能通常需要更长的时间。通常可以在编写测试之前完成重构。在这种情况下，写作单元测试仍然具有长期效益，但您必须进一步考虑长期利益是否适合直接成本。

通常，我总是会推动某种形式的自动化测试，无论是单元还是功能，尽管遗留代码库需要额外的成本。没有它，您可能会发现自己陷入了难以维护的代码库，并且需要不断进行重复的手动测试，以确保它能够继续运行，并且频繁回归。