是否可以为程序中的每个类编写测试用例？

Question

我刚刚开始介绍单元测试和测试驱动开发。到目前为止，我只使用Junit作为测试框架。出现了一个我尚未找到明确答案的问题是：我需要编写多少测试用例？我是否必须为我的程序中的每个类编写一个测试用例？或者这是一个愚蠢的问题，因为单元测试意味着在最低（即类）级别进行测试？

我认为为每个班级编写一个测试用例可能是更安全的方法（毕竟你测试的越多，意外错误的数量越少）。但我想知道是否有关于编写测试用例数量的广泛认可的策略？

Answer 1

如果您正在尝试使用TDD，那么在没有告知您这样做的失败测试的情况下，您根本不应该编写任何代码。通过暗示，你将永远不会有一个没有一个或多个测试的类。一个经常被引用的经验法则是你应该得到大约2.5倍的测试源作为主要来源。

Answer 2

此领域没有严格的规定，只有指导方针。每个类通常有一个测试用例，但有不同的策略：

• TestCase Per Class
• TestCase Per Feature
• TestCase Per Method
• TestCase Per User Story

例如，您可以对相对较小的类使用“Per Class”方法，并遵循SRP。但是如果你有一个巨大的* Manager类的遗留代码，可以使用'Per Method'并且只为其中一个方法提供专用的测试用例。我认为选择测试的命名策略至少与测试代码组织一样重要。

使用code coverage工具可以帮助您找到未经测试的代码点。它作为指标不太有用。拥有高代码覆盖率并不一定意味着您有良好的测试。在一天结束时，重要的是你有meaningful and readable tests.

Answer 3

我不建议每个类严格映射一个测试。有些课程可能没有多少值得自己测试。某些类可能需要多次测试，因为您要为不同的情况指定不同的设置。你应该使用像Cobertura这样的代码覆盖工具，尽量覆盖尽可能多的代码。此外，您应该查看您正在测试的代码，看看哪种不同的数据应该破坏它，并尝试使用不同的样本数据组合对其进行测试（因此100％的代码覆盖率当然不是测试的结束）。

Answer 4

虽然优于1：1的比例或超过100％的覆盖率是理想的，但总的来说，我倾向于遵守“测试可能会破坏的”。

这意味着只用“工作部件”测试代码。这不包括POJO，DTO，瘦包装器/适配器类以及仅适合框架的类，等等。

此外，“仅测试您控制的代码”。这通常意味着不为生成的代码编写显式测试 - 例如从WSDL生成的Web服务客户端（但仍然有必要将它们作为为您自己的类编写的测试的一部分）。

Answer 5

如果您正在进行TDD和极限编程，（我认为这有助于解释它），您可以成对编程。第一个人为尚不存在的功能编写测试。测试应证明该功能100％正常运行并处理所有必需的案例。然后，第二个程序员编写使测试完全通过的代码。必须重写它才能完全满足测试要求。通常你会为TDD维护一个测试套件，可以不断重新运行，检测任何故障并生成报告 - 尽管这对个人用途很有用。

在任何情况下，对于TDD，如果没有首先进行新测试，则不能存在新功能 - 测试驱动开发。因此，如果您正确执行此操作，默认情况下您的测试适用于所有功能。

Answer 6

我并不像其他评论员那样严格地写下测试拳和代码。你应该这样做，但实际上并没有多少人这样做。重要的是在编写代码之前或者在编写代码之后立即编写测试。但不是之后的几天/几周/几个月/几年，因为你不会这样做而且测试会很糟糕。

我通常将应用程序划分为几个部分：应用程序逻辑，业务逻辑，数据访问层，域对象和帮助程序类。完全测试业务逻辑和帮助程序类是最重要的。其他应用部分不太重要，但您可以测试一些部件。还做一些集成测试。

最重要的是不要过度思考它。试着在一个小项目上做，你会自己看。