是否存在过多的单元测试？

Question

我试着查看有关单元测试的所有页面，但找不到这个问题。如果这是重复，请告诉我，我将删除它。

我最近的任务是帮助我公司实施单元测试。我意识到我可以对所有Oracle PL / SQL代码，Java代码，HTML，JavaScript，XML，XSLT等进行单元测试。

是否有太多的单元测试？我应该为上述所有内容编写单元测试还是过度杀伤？

Answer 1

这取决于项目及其对失败的容忍度。没有一个答案。如果您可以冒险，那么不要测试所有内容。

当您进行大量测试时，您的测试中也可能存在错误。令您头疼的是。

测试需要测试的内容，留下不适合的内容，这通常会留下相当简单的内容。

Answer 2

  

是否存在太多的单元测试？

不确定。问题是在足够的单元测试之间找到适当的平衡，以涵盖功能的重要领域，并集中精力在系统功能方面为客户创造新的价值。

单元测试代码与测试未覆盖的离开代码都有成本。

从单元测试中排除代码的成本可能包括（但不限于）：

• 由于您无法自动测试的修复问题而导致开发时间延长
• 修复质量检查测试期间发现的问题
• 修复代码到达客户时发现的问题
• 由于客户对通过测试的缺陷不满意导致的收入损失

编写单元测试的成本包括（但不限于）：

• 编写原始单元测试
• 在系统发展过程中维护单元测试
• 在测试或生产中发现它们时，优化单元测试以涵盖更多条件
• 重构单元测试作为被测试的底层代码重构
• 当您的申请进入市场需要更长时间时收入损失
• 实施可以推动销售的功能的机会成本

您必须对这些成本可能是什么做出最佳判断，以及您对吸收此类成本的容忍度。

一般而言，单元测试成本主要在系统开发阶段吸收 - 有些在维护期间。如果您花费太多时间编写单元测试，您可能会错过将产品推向市场的宝贵机会之窗。如果您在竞争激烈的行业中经营，这可能会使您的销售成本甚至长期收入。

缺陷成本在生产系统的整个生命周期内被吸收 - 直至缺陷得到纠正。而且，甚至可能超出这个范围，如果它们的缺陷足够严重，它会影响公司的声誉或市场地位。

Answer 3

肯特贝克JUnit和JUnitMax成名answered我的question。 这个问题的语义略有不同，但答案肯定是相关的

Answer 4

单元测试的目的通常是为了使它可以更好地改进或改变，更确保你没有破坏任何东西。如果变化是可怕的，因为你不知道你是否会破坏任何东西，你可能需要添加一个测试。如果改变是繁琐的，因为它会破坏很多测试，那么你可能有太多的测试（或者测试太脆弱）。

最明显的案例是用户界面。使UI看起来很好的东西很难测试，使用主示例往往是脆弱的。因此，涉及外观的UI层不会被测试。

另一些​​可能不值得的是，如果测试很难写，并且它给出的安全性很小。

对于HTML，我倾向于检查我想要的数据是否存在（使用XPath查询），但没有测试整个HTML。类似地，对于XSLT和XML。在JavaScript中，当我可以测试库但只留下主页时（除了我将大多数代码移动到库中）。如果JavaScript特别复杂，我会测试更多。对于数据库，我将研究测试存储过程和可能的视图;其余的更具说服力。

但是，在你的情况下，首先要考虑最让你担心或即将改变的东西，特别是如果它不太难以测试。查看书籍Working Effectively with Legacy Code以获取更多帮助。

Answer 5

是的，有太多的单元测试。一个例子是以白盒方式进行单元测试，这样您就可以有效地测试特定的实现;这样的测试会通过要求兼容代码需要新的单元测试来有效地减缓进度和重构（因为测试取决于具体的实现细节）。

Answer 6

我建议在某些情况下，您可能需要自动化测试，但根本不需要“单元”测试（Should one test internal implementation, or only test public behaviour?），并且编写单元测试所花费的任何时间都可以更好地用于编写系统测试。

Answer 7

虽然更多的测试通常会更好（我还没有参与一个实际上太多测试的项目），但是ROI已经到了最低点，你应该继续前进。顺便说一句，我假设你有足够的时间来完成这个项目。 ;）

添加单元测试会有一些收益递减 - 在某一点之后（Code Complete有一些理论），你最好把有限的时间用在别的东西上。这可能是更多测试/质量活动，如重构和代码审查，与真人类用户的可用性测试等，或者它可能花在其他事情上，如新功能或用户体验抛光。

Answer 8

正如EJD所说，你无法验证是否存在错误。

这意味着您可以编写更多测试。任何这些都可能有用。

您需要了解的是，单元测试（以及您用于开发目的的其他类型的自动化测试）可以帮助开发，但永远不应被视为正式QA的替代。

有些测试比其他测试更有价值。

您的代码的某些部分会更频繁地更改，更容易破坏等等。这些是最经济的测试。

您需要平衡您同意作为开发人员所承担的测试数量。您可以通过不可维护的测试轻松地让自己负担过重。 IMO，不可维护的测试比没有测试更糟糕，因为他们：

1. 让其他人试图维护测试套件或编写新测试。
2. 从中添加新的有意义的功能。如果自动化测试不是一个净结果，那么你应该像其他工程实践一样抛弃它。

我应该测试什么？

测试“快乐路径” - 这可以确保您正确地进行交互，并确保事情正确连接在一起。但是你没有在没有交通的阳光灿烂的日子里通过驾驶来充分测试桥梁。

实用单元测试建议您使用Right-BICEP来确定要测试的内容。对于快乐路径“正确”，然后 B 条件，检查任何我反向关系，使用另一种方法（如果存在） C ross-check结果，强制 E rror条件，并最终考虑应验证的任何 P 性能注意事项。我会说如果你考虑用这种方式编写测试，你很可能会弄清楚如何达到足够的测试水平。你将能够找出哪些更有用，何时更有用。有关更多信息，请参阅该书。

在适当的级别进行测试

正如其他人所提到的，单元测试并不是编写自动化测试的唯一方法。其他类型的框架可以基于单元测试构建，但提供进行包级别，系统或集成测试的机制。最好的降压可能是更高的水平，只需使用单元测试来验证单个组件的快乐路径。

不要气馁

我在这里画的画面比我希望大多数开发人员在实际中找到的画面更加严峻。最重要的是，您承诺学习如何编写测试并将其写好。但是，不要让对未知的恐惧吓到你不写任何测试。与生产代码不同，测试可以被抛弃和重写，而不会产生很多不利影响。

Answer 9

对您认为可能会更改的任何代码进行单元测试。

Answer 10

您应该只为自己编写的任何代码编写单元测试。无需测试固有提供给您的功能。

例如，如果您已经获得了一个带有add函数的库，那么您不应该测试add（1,2）返回3.现在如果您已经编写了该代码，那么是的，您应该进行测试它

当然，编写图书馆的人可能没有对其进行测试，但可能无法正常工作......在这种情况下，您应该自己编写或者获得具有相同功能的单独版本。

Answer 11

嗯，你当然不应该对所有内容进行单元测试，但至少是复杂的任务或那些很可能包含你没有想到的错误/案例的任务。

Answer 12

单元测试的重点是能够运行一组快速测试来验证您的代码是否正确。这使您可以验证代码是否符合您的规范，还可以进行更改并确保它们不会破坏任何内容。

使用你的判断。您不想花费所有时间编写单元测试，或者您没有时间编写实际代码进行测试。

Answer 13

当您对单元测试进行单元测试时，认为您已经提供了200％的覆盖率。

Answer 14

有一种称为测试驱动开发的开发方法，基本上说没有太多（非冗余）单元测试。然而，这种方法不是一种测试方法，而是一种设计方法，它依赖于工作代码和一个或多或少完整的单元测试套件，其中的测试可以驱动关于代码库的每一个决策。< / p>

在非TDD情况下，自动化测试应该运行您编写的每一行代码（特别是分支覆盖率很好），但即便如此，也有例外 - 您不应该测试供应商提供的平台或框架代码，除非你肯定知道在那个平台上会有一些影响你的错误。你不应该测试薄包装器（或者，同样，如果你需要测试它，包装器不薄）。您应该测试所有核心业务逻辑，并且在某些基本级别上运行数据库的一组测试肯定是有帮助的，尽管这些测试在每次编译时都运行单元测试的常见情况下永远不会起作用。

特别是关于数据库测试本质上很慢，并且根据数据库中保存的逻辑数量，很难做到正确。通常是像dbs，HTML / XML文档和＆amp;模板和模板的其他文档方面都经过验证，而不是经过测试。不同之处通常是测试试图执行执行路径，而验证试图直接验证输入和输出。

要了解有关此内容的更多信息，我建议您阅读“代码覆盖率”。如果您对此感到好奇，可以使用很多材料。