我刚刚开始接触单元测试和测试驱动开发。到目前为止，我只使用Junit作为测试框架。出现了一个问题，我还没有找到一个明确的答案：我需要写多少测试用例？我必须为程序中的每个类写一个测试用例吗？或者这是一个愚蠢的问题，因为单元测试意味着在最低级别（即类）进行测试？我认为为每个类编写一个测试用例可能是更安全的方法（毕竟你测试的越多，不可预见的bug的数量就越少）。
uplii1fm1#
如果你正在尝试TDD，那么你不应该在没有失败测试的情况下编写任何代码。这意味着，你永远不会有一个没有一个或多个测试的类。一个经常被引用的经验法则是，你最终应该拥有大约2.5倍于主源代码的测试源代码。
w8rqjzmb2#
在这个领域没有严格的规则，只有指导方针。通常每个类有一个测试用例，但有不同的策略：
例如，你可以对相对较小的类使用“Per Class”方法，并且遵循SRP。但是如果你有一个巨大的 *Manager类的遗留代码，那么使用“Per Method”并为其中一个方法提供专用的测试用例是可以的。我认为选择测试的命名策略至少和测试代码组织一样重要。使用code coverage工具可以帮助您找到未测试的代码点。它作为度量标准的用处不大。具有高代码覆盖率并不一定意味着您有良好的测试。最终，重要的是您有meaningful and readable tests.
vcudknz33#
我不建议每个类一个测试的严格Map。有些类可能没有太多值得测试的地方。有些类可能需要多个测试，因为你想为不同的情况指定不同的设置。你应该使用像Cobertura这样的代码覆盖工具，并尝试覆盖尽可能多的代码。你还应该看看你正在测试的代码，看看什么样的不同数据会破坏它，并尝试用不同的样本数据组合来测试它（所以100%的代码覆盖率当然不是测试的终点）。
qvk1mo1f4#
虽然超过1：1的比例或超过100%的覆盖率是理想的，但一般来说，我倾向于遵守“测试可能会打破”。这意味着只测试具有“工作部分”的代码，不包括POJO、DTO、瘦 Package 器/适配器类和仅为适应框架而存在的类等。另外，“只测试在您控制之下的代码”。这通常意味着不为生成的代码编写显式测试--例如从WSDL生成的Web服务客户端（但将它们作为为您自己的类编写的测试的一部分仍然是有意义的）。
hgncfbus5#
如果你在做TDD和极限编程，（我认为这有助于解释它），你两人一组编程。第一个人为一个还不存在的功能写一个测试。这个测试应该证明这个功能是100%正确的然后第二个程序员编写使测试完美通过的代码。它必须被重写，直到它完全满足测试。通常，你维护一个TDD测试套件，它可以不断地进行测试，检测任何故障并生成报告-尽管这对于个人使用来说是雄心勃勃的。在任何情况下，对于TDD来说，一个新的功能不可能在没有一个新的测试的情况下存在-测试驱动开发。所以，如果你做得对，你的测试默认会出现在每个功能上。
cs7cruho6#
我并不像其他评论者那样严格要求先写测试，然后再写代码。你应该这样做，但实际上没有多少人这样做。重要的是在写代码之前写测试，或者在写代码之后写测试。但不是在那之后的几天/几周/几个月/几年，因为你不会这样做，测试会很糟糕。我通常将应用程序分为几个部分：应用程序逻辑、业务逻辑、数据访问层、域对象和助手类。完整地测试业务逻辑和助手类是最重要的。应用程序的其他部分不太重要，但你可以测试一些部分。也可以做一些集成测试。最重要的是不要想太多，试着在一些小项目上做，你自己会看到的。
lx0bsm1f7#
Bob叔叔（Clean Code的作者）的这句话可能会回答你的问题：你的测试结构不应该是你代码结构的镜像。你有一个名为X的类的事实不应该自动暗示你有一个名为XTest的测试类。Source通过将测试耦合到代码结构，当代码更改时，测试更有可能更改，使测试更脆弱（例如，在重构过程中，当类被拆分或合并时）。
7条答案
按热度按时间uplii1fm1#
如果你正在尝试TDD，那么你不应该在没有失败测试的情况下编写任何代码。这意味着，你永远不会有一个没有一个或多个测试的类。一个经常被引用的经验法则是，你最终应该拥有大约2.5倍于主源代码的测试源代码。
w8rqjzmb2#
在这个领域没有严格的规则，只有指导方针。通常每个类有一个测试用例，但有不同的策略：
例如，你可以对相对较小的类使用“Per Class”方法，并且遵循SRP。但是如果你有一个巨大的 *Manager类的遗留代码，那么使用“Per Method”并为其中一个方法提供专用的测试用例是可以的。我认为选择测试的命名策略至少和测试代码组织一样重要。
使用code coverage工具可以帮助您找到未测试的代码点。它作为度量标准的用处不大。具有高代码覆盖率并不一定意味着您有良好的测试。最终，重要的是您有meaningful and readable tests.
vcudknz33#
我不建议每个类一个测试的严格Map。有些类可能没有太多值得测试的地方。有些类可能需要多个测试，因为你想为不同的情况指定不同的设置。你应该使用像Cobertura这样的代码覆盖工具，并尝试覆盖尽可能多的代码。你还应该看看你正在测试的代码，看看什么样的不同数据会破坏它，并尝试用不同的样本数据组合来测试它（所以100%的代码覆盖率当然不是测试的终点）。
qvk1mo1f4#
虽然超过1：1的比例或超过100%的覆盖率是理想的，但一般来说，我倾向于遵守“测试可能会打破”。
这意味着只测试具有“工作部分”的代码，不包括POJO、DTO、瘦 Package 器/适配器类和仅为适应框架而存在的类等。
另外，“只测试在您控制之下的代码”。这通常意味着不为生成的代码编写显式测试--例如从WSDL生成的Web服务客户端（但将它们作为为您自己的类编写的测试的一部分仍然是有意义的）。
hgncfbus5#
如果你在做TDD和极限编程，（我认为这有助于解释它），你两人一组编程。第一个人为一个还不存在的功能写一个测试。这个测试应该证明这个功能是100%正确的然后第二个程序员编写使测试完美通过的代码。它必须被重写，直到它完全满足测试。通常，你维护一个TDD测试套件，它可以不断地进行测试，检测任何故障并生成报告-尽管这对于个人使用来说是雄心勃勃的。
在任何情况下，对于TDD来说，一个新的功能不可能在没有一个新的测试的情况下存在-测试驱动开发。所以，如果你做得对，你的测试默认会出现在每个功能上。
cs7cruho6#
我并不像其他评论者那样严格要求先写测试，然后再写代码。你应该这样做，但实际上没有多少人这样做。重要的是在写代码之前写测试，或者在写代码之后写测试。但不是在那之后的几天/几周/几个月/几年，因为你不会这样做，测试会很糟糕。
我通常将应用程序分为几个部分：应用程序逻辑、业务逻辑、数据访问层、域对象和助手类。完整地测试业务逻辑和助手类是最重要的。应用程序的其他部分不太重要，但你可以测试一些部分。也可以做一些集成测试。
最重要的是不要想太多，试着在一些小项目上做，你自己会看到的。
lx0bsm1f7#
Bob叔叔（Clean Code的作者）的这句话可能会回答你的问题：
你的测试结构不应该是你代码结构的镜像。你有一个名为X的类的事实不应该自动暗示你有一个名为XTest的测试类。
Source
通过将测试耦合到代码结构，当代码更改时，测试更有可能更改，使测试更脆弱（例如，在重构过程中，当类被拆分或合并时）。