我刚刚开始了解单元测试和测试驱动开发。到目前为止，我只使用 Junit 作为测试框架。出现了一个我还没有找到明确答案的问题：我需要编写多少测试用例？我必须为程序中的每个类编写一个测试用例吗？或者这是一个愚蠢的问题，因为单元测试意味着在最低（即类）级别进行测试？
我认为为每个类编写一个测试用例可能是更安全的方法（毕竟你测试的越多，意外错误的数量就越少）。但我想知道对于要编写的测试用例数量是否有任何广泛认可的策略？
【问题讨论】：
标签： java unit-testing junit
如果您正在尝试 TDD，那么您根本不应该在没有失败的测试告诉您这样做的情况下编写任何代码。因此，暗示你永远不会有一个没有一个或多个测试的类。一个经常被引用的经验法则是，您最终得到的测试源应该是主要源的 2.5 倍。
【讨论】：
这方面没有严格的规定，只有指导方针。通常每个类都有一个测试用例，但有不同的策略：
例如，您可以对相对较小的类使用“每类”方法并遵循SRP。但是，如果您有带有巨大 *Manager 类的遗留代码，则可以使用“Per Method”并仅针对其中一种方法使用专用测试用例。我认为为测试选择命名策略至少与测试代码组织一样重要。
使用code coverage 工具可以帮助您找到未经测试的代码点。它作为度量的用处不大。拥有高代码覆盖率并不一定意味着您拥有良好的测试。归根结底，重要的是你有meaningful and readable tests.
【讨论】：
我不建议每个班级严格映射一个测试。有些类本身可能没有太多值得测试的地方。某些类可能需要多次测试，因为您想为不同的情况指定不同的设置。您应该使用 Cobertura 之类的代码覆盖工具，并尝试覆盖尽可能多的代码。此外，您应该查看您正在测试的代码，看看哪些不同的数据会破坏它，并尝试使用不同的样本数据组合对其进行测试（因此，100% 的代码覆盖率当然不是测试的结束）。
【讨论】：
虽然优于 1:1 的比例或超过 100% 的覆盖率是理想的，但总的来说，我倾向于遵守“测试可能会破坏的东西”。
这意味着只测试带有“工作部分”的代码。这不包括 POJO、DTO、瘦包装器/适配器类以及仅存在以适应框架的类等。
另外，“仅测试您控制的代码”。这通常意味着不要为生成的代码编写显式测试，例如从 WSDL 生成的 Web 服务客户端（但将它们作为为您自己的类编写的测试的一部分进行覆盖仍然是有意义的）。
【讨论】：
如果你正在做 TDD 和极限编程，（我认为这有助于解释它），你需要成对编程。第一个人为尚不存在的功能编写测试。测试应该证明该功能是 100% 的功能并处理所有必需的情况。然后第二个程序员编写使测试完美通过的代码。它必须重写，直到它完全满足测试。通常你会维护一个 TDD 测试套件，它可以不断地重新运行，检测任何故障并生成报告——尽管这对于个人使用来说是雄心勃勃的。
在任何情况下，对于 TDD，如果不首先进行新测试，就不可能存在新功能 - 测试驱动开发。因此，如果您操作正确，默认情况下您的每个功能都会进行测试。
【讨论】：
我并不像其他评论者那样严格要求之后编写测试拳头和代码。你应该这样做，但实际上没有多少人这样做。重要的是最好在编写代码之前或在编写代码之后编写测试。但不是在那之后的几天/几周/几个月/几年，因为你不会这样做，测试会很糟糕。
我通常将应用程序分为几个部分：应用程序逻辑、业务逻辑、数据访问层、领域对象和帮助类。测试完整的业务逻辑和助手类是最重要的。应用程序的其他部分不太重要，但您可以测试一些部分。也做一些集成测试。
最重要的是不要想太多。试着在一些小项目上做，你会自己看到的。
【讨论】：