确定单元测试的最佳数量？

Question

我想我可能写了太多单元测试。

例如，假设我在做一个课程管理系统，我为一个学生编写了一个提交课程作业的功能。如果在API调用中指定了无效的凭据，则返回禁止的401。如果学生试图提交不同学生的课程作业，则返回不同的错误。如果一名学生提交自己的课程作业，它被接受，但处于“待定”的状态，等待工作人员的批准。如果一名教员代表一名学生发送课程作业，它会自动被接受，并自动进入“认可”状态。

正如您所看到的，这里大约有4-5个不同的场景，每个场景都有不同的结果。

我倾向于为每个场景编写测试。这意味着，我可能需要10-15分钟来编写这个特性，然后再用15分钟-一个小时来编写和通过所有的单元测试。可能还要两个小时。

很明显，这让我慢了下来，人们期望我能更快地交付结果。但是，除非我编写了所有这些测试，否则感觉是“错误的”，而且代码可能不会像预期的那样工作。

这里的解决方案是什么？需要编写的单元测试的正确数量是多少？每1小时的编码，最大的时间，应该花多少时间，为该功能编写测试？

Answer 1

您所描述的每一个结果都是有效的测试方案。你所知道的方式是每一种行为都与不同的结果联系在一起。这使得每个人都成为测试的主要候选人。

从圈复杂度的角度来看，每个测试的不同结果对应于不同的程序状态，这几乎肯定意味着您通过代码测试不同的路径，从而提高了测试代码的覆盖率。

如果您只是一遍又一遍地测试相同的行为并断言相同的结果，那么我可能会担心您编写的测试太多了。但是如果每个测试都是在测试一个特定的行为和结果的话，就不会了。

Answer 2

钉子上的锤子--如果木头裂开了，你应该用螺丝钉

你怎么知道你写的测试不够？如果错误出现在上游，可能在单元测试阶段被捕获，那么您还没有编写足够的测试。

但撇开这一点不说，我感觉到你同样感兴趣的是花费的精力来阻止可能出现的bug。如果您发现自己正在编写代码以覆盖相同的参数范围或组合，那么像NUnit这样的框架就会占用大量的辅助工作。但是，如果它们是真正的业务案例，那么您只需咬紧牙关，根据需要编写尽可能多的代码。这方面没有经验法则--有些代码编写得非常快，但很难测试，反之亦然。

Answer 3

在创造和测试之间总是有一个权衡，我可以创造一个完美的产品，10年后再来，它就会准备好。任何经理都不会接受这样的估计(或成本:)

因此，您必须务实，单元测试不能捕获所有的bug，所以您不应该尝试创建100%完美的单元测试环境和100%的代码覆盖率。您可以将20%的时间用于编写80%的测试，其余的时间用于编写您需要完成的集成测试。

然而，你的问题中有一部分是很突出的：

编写并通过所有单元测试。

现在，使代码工作从而通过测试所花费的时间应该被认为是在初始编码阶段花费的时间。你可以破译任何旧的垃圾代码，并说“完成！”但是它并没有真正完成--您只是推迟了一些编码时间(当发现bug时)或其他人(更糟糕的是，修复您自己的烂摊子)。因此，不要认为编写代码就是它的结束，测试突出显示的修复代码所花费的时间是编码时间，而不是测试时间。

所以回答你的问题。我更喜欢主要的集成测试，所以我不会对所有东西进行单元测试。我倾向于只对代码中复杂或笨拙的部分进行单元测试。因此，我不会试图限制花费在测试上的时间，而是优先考虑需要测试的内容。如果一个简单的方法足够简单，它只为一个getter编写一个单元测试就没有意义，那么就可以直观地检查它是否正确。然后，您可以花费更多的时间给这些复杂的方法进行它们应得的测试，从而节省您花费在测试琐碎上的时间，并且您的整体质量和效率应该会提高。