我们通常应该花多长时间编写用于新功能或错误修复的单元测试？

当我必须实施新功能或修复错误时，我通常尝试通过测试来重新创建情况。我有时花大约3个小时来准备夹具并编写测试。实际的功能实现或错误修复不到1小时即可完成。

与实际实现功能或修复错误相比，其他人花费至少3倍的时间编写测试吗？编写测试与编写代码所花费的时间可接受的比率是多少？

它取决于错误或功能的复杂性。我记得有一个项目曾经有1.5周的开发预算估算和3个月的测试估算。代码更改很小，到处都是几行，但是它以多种方式影响了保险系统的许多组件，因此必须进行彻底的测试。还有一次，有一个错误，在错误的地方包含了括号。花了2个小时来找到它，花了2秒钟来解决它，但是花了大约一周的时间来测试可能受逻辑更改影响的数十种情况。

通常，我不担心花费在编码上的时间与花费在测试上的时间之比，因为这是不准确的。我发现在某些项目中，项目相对比率似乎通常是标准的（对项目而言），但即使这样以后也可以更改。

如需要说的大部分时间都与信心的代码工作正常。

您如何花足够的时间编写测试，直到您证明该功能可以按预期运行或错误已正确修复。

每种情况都会有所不同；不能有某种比率。一些测试将花费实施时间的十分之一，而另一些则将花费数百倍的时间。

在项目中引入单元测试后，我曾经做过一次粗鲁的测试。结果是：花费在编写测试上的时间大约是执行时间的40％。但是，我们的目标并不是在那里进行全面报道，这是一个结构完善，结构牢固且惯例规范的项目。

我想说时间编码与编写单元测试的时间应该大致相等。有时可能会多一点。看看这篇关于SO的文章，它花费在编码与单元测试上的时间比率

你算对了吗？为了准确核算您在测试上花费了多少时间，您需要编写没有测试的代码。

如果确实花了三个小时编写测试并花了一个小时才能通过测试，那么您可能会发现，在不编写测试的情况下修复同一错误需要5个小时以上。

是的，我花在测试上的时间通常比实际的修复代码多得多。