会不会有太多的单元测试？

Question

我的任务是为现有的应用程序编写单元测试。在完成我的第一个文件后，我有717行测试代码，用于419行原始代码。

随着代码覆盖率的增加，这一比率会变得难以管理吗？

我对单元测试的理解是测试类中的每个方法，以确保每个方法都按预期工作。然而，在拉请求中，我的技术主管指出，我应该把重点放在更高级别的测试上。他建议测试4-5用例，这些用例最常与所讨论的类一起使用，而不是详尽地测试每个函数。

我相信我的技术主管的意见。他比我有更多的经验，在软件设计方面他有更好的直觉。但是，一个多人团队如何为这样一个模糊的标准编写测试；也就是说，我如何认识我的同行和我对“最常见的用例”有相同的想法？

对我来说，100%的单元测试覆盖率是一个崇高的目标，但是即使我们只达到了50%，我们也知道这50%中的100%已经被覆盖了。否则，为每个文件的一部分编写测试会留下很大的欺骗空间。

Answer 1

是的，有了100%的覆盖率，您将编写一些您不需要的测试。不幸的是，确定您不需要的测试的唯一可靠方法是编写所有测试，然后等待10年左右，看看哪些测试从未失败。

维护大量的测试通常不会有问题。许多团队在100%单元测试覆盖率的基础上进行了自动集成和系统测试。

但是，您还没有处于测试维护阶段，您正在追赶。让100%的班级达到50%的测试覆盖率要比在100%的测试覆盖率下拥有50%的班级要好得多，而且您的领导似乎试图让您相应地分配时间。在有了基线之后，接下来的步骤通常是在向前修改的文件中推动100%。

Answer 2

如果您在使用创建的大型代码库上工作过，您就已经知道会有太多的单元测试。在某些情况下，大多数开发工作包括更新低质量的测试，这些测试最好在运行时作为不变量、先决条件和后置条件检查在相关类中实现(即测试作为更高级别测试的副作用)。

另一个问题是使用货崇拜驱动的设计技术来创建低质量的设计，这会导致大量的测试(更多的类、接口等)。在这种情况下，负担似乎是更新测试代码，但真正的问题是质量差的设计。

Answer 3

回答您的问题

会不会有太多的单元测试？

当然..。例如，您可以有多个测试，这些测试乍一看似乎不同，但实际上测试的内容是相同的(逻辑上取决于测试中的“有趣”应用程序代码的相同行)。

或者，您也可以测试代码的内部组件，这些内部元素永远不会外露(即，它不是任何类型的接口契约的一部分)，在这种情况下，人们可能会争论这是否有意义。例如，内部日志消息或其他任何内容的确切措辞。

我的任务是为现有的应用程序编写单元测试。在完成我的第一个文件后，我有717行测试代码，用于419行原始代码。

我觉得这很正常。您的测试在安装和实际测试之上花费了大量代码行。这一比率可能会提高，也可能不会提高。我自己的测试很重，经常比实际代码投入更多的L-o和时间在测试上。

随着代码覆盖率的增加，这一比率会变得难以管理吗？

这一比率并没有考虑这么多因素。测试的其他特性往往会使它们无法管理。如果您在代码中进行相当简单的更改时，经常需要重构大量测试，那么您应该仔细看看原因。这些不是你有多少行，而是你如何处理测试的编码。

我对单元测试的理解是测试类中的每个方法，以确保每个方法都按预期工作。

这对于严格意义上的“单元”测试是正确的。在这里，“单元”是某种类似于方法或类的东西。“单元”测试的重点是只测试一个特定的代码单元，而不是整个系统。理想情况下，您可以删除整个系统的其余部分(使用双倍或诸如此类)。

然而，在拉请求中，我的技术主管指出，我应该把重点放在更高级别的测试上。

然后，当人们说单元测试时，你就陷入了假设人们实际上是指单元测试的陷阱。我见过许多程序员，他们说“单元测试”，但含义完全不同。

他建议测试4-5用例，这些用例最常与所讨论的类一起使用，而不是详尽地测试每个函数。

当然，专注于最重要的80%的代码也可以减少负载.我很感激你对你老板的高度评价，但我并不认为这是最佳选择。

对我来说，100%的单元测试覆盖率是一个崇高的目标，但是即使我们只达到了50%，我们也知道这50%中的100%已经被覆盖了。

我不知道什么是“单元测试覆盖率”。我假设您的意思是“代码覆盖率”，即在运行测试套件之后，每一行代码(=100%)至少执行一次。

这是一个不错的大概的度量，但到目前为止，还不是最好的标准之一。仅仅执行代码行并不是全部；例如，这并不能解释通过复杂的嵌套分支的不同路径。更多的是一种度量，它将手指指向测试过少的代码片段(显然，如果一个类的代码覆盖率为10%或5%，那么就有问题了)；另一方面，100%的覆盖率并不能告诉您测试是否已经足够或者测试是否正确。

集成测试

在默认情况下，当人们今天不断地谈论单元测试时，这让我非常恼火。在我看来(和经验)，单元测试对于库/API是很好的；在更面向业务的领域(在这里我们讨论的是问题中的用例)，它们不一定是最好的选择。

对于一般的应用程序代码和一般业务(在这些业务中，赚钱、按时完成任务和满足客户满意是很重要的，而且您主要希望避免那些直接出现在用户面前或可能导致真正灾难的bugs -我们这里不是在谈论NASA火箭发射)，集成或特性测试更有用。

它们与行为驱动的开发或特性驱动的开发密切相关；根据定义，这些开发与(严格的)单元测试无关。

为了保持它的简短(Ish)，集成/特性测试将练习整个应用程序栈。在基于web的应用程序中，它的作用就像浏览器在应用程序中单击一样(不，很明显，它不需要那么简单，有非常强大的框架可以这样做--看看http://cucumber.io的例子)。

哦，回答你最后的问题:你让你的整个团队有一个高的测试覆盖率，确保一个新的功能只有在其特性测试已经实现并失败后才被编程。是的，这意味着每一个特征。这保证了您100% (积极)的功能覆盖范围。根据定义，它保证应用程序的一个功能永远不会“消失”。它不能保证100%的代码覆盖率(例如，除非您主动编写负面特性，否则您将不会执行错误处理/异常处理)。

它并不保证您是一个没有bug的应用程序；当然，您会希望为明显或非常危险的错误情况、错误的用户输入、黑客(例如，周围的会话管理、安全性等)编写特性测试；但是，即使只对阳性测试进行编程，也有很大的好处，而且在现代强大的框架中也是可行的。

特性/集成测试显然有它们自己的蠕虫(例如，性能；第三方框架的冗余测试；因为您通常不使用双重测试，根据我的经验.)，但在100%的代码覆盖单元测试应用程序(而不是库！)上，我会采用100%的阳性特性测试应用程序。任何一天。