unit-testing - Ratio of time spent on coding versus unit testing

Question

What is a typical estimate for coding unit tests given an estimate for coding new functionality? Is this different for estimates to maintain code?

Answer 1

我的时间在单元测试时间和功能代码时间之间大致相等。

有些人会认为这是浪费时间，但如果您唯一的选择是运行应用程序并逐步检查应用程序可以采用的所有可能路径，那么单元测试所花费的时间实际上少于您将花费在开发人员测试上的时间。当然，如果您不做太多的开发人员测试，那么您将花时间修复来自 QA 的错误。

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

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

但是，您在测试时间上节省的时间要大得多；您已经创建了涵盖其余代码的测试，因此您无需任何新代码或运行应用程序即可发现因更改而产生的任何偶然更改。

Answer 2

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

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

Answer 3

我发现它根据您正在使用的代码而有很大差异 - 当从头开始编写测试驱动的东西时，实现该功能可能需要与没有测试相同的时间，但是您可以在数量上节省更长的时间将发现的错误数量，以及维护和扩展该代码库的难易程度。有人可能会争辩说，在这种情况下使用测试编写会更快，因为您可以避免那些令人头疼的时刻，即代码的行为与预期不符，并且您必须使用调试器来找出正在发生的事情，范围更广比 TDD 通常允许的更改集。

当您尝试在现有的“遗留”代码库（正如 Michael Feathers 定义的遗留代码）之上实现功能时，由于必须进行大量仔细的重构，因此通过测试实现该功能通常比不使用该功能需要更长的时间在编写测试之前完成通常是可能的。在这种情况下，编写单元测试仍然会带来长期利益，但您必须额外考虑这种长期利益是否适合直接成本。

一般来说，我总是会推动某种形式的自动化测试，无论是单元测试还是功能测试，尽管遗留代码库会产生额外成本。没有它，您可能会发现自己的代码库很难维护，需要不断重复的手动测试以确保它继续运行，并且经常出现回归。