单元测试的测试用例答案

【问题标题】：test cases for unit testing单元测试的测试用例
【发布时间】：2023-03-27 19:37:02
【问题描述】：

在我的项目中，我看到我们有大量的方法来测试某些东西。如果你想了解发生了什么，你应该看看 throw all 方法。当您有一个包含 20 种测试方法的类时，您很难在这么多方法中找到一个/多个测试用例。

我从未见过使用接口来定义测试用例涵盖的内容。

例如

   puclic class A{
     public SomeResult doSomething(Param param){
       .....
      }
     ..... some other methods
   }

对于这种方法有4种情况（例如）；

使用空参数检查方法是否按预期工作
检查方法是否为某些参数区域抛出运行时异常
检查方法是否返回预期结果（正常情况）
检查不同的东西

在我们测试这些案例的项目中，人们只需创建 4 个方法（它们可以按任何顺序编写，例如测试类开头出现的 2 个第一个案例，最后一秒可以写在末尾（200 行代码）以下））。另外从测试的名称中也不一定能清楚地知道检查的测试方法。

这样在接口中描述测试用例是不是很好：

public interface ATestSpecification{
    void doSomething_checkForNullParam();
    void doSomething_checkExceptionForNotAllowedParam();
    void doSomething_normalCase();
    void doSomething_checkSomethingDifferent();
}

还有测试课：

public class ATest implement ATestSpecification{
...
//implenent test cases , described in test specification
...
}

【问题讨论】：

标签： unit-testing junit

【解决方案1】：

由于开发人员测试本质上是文档，并且为了方便开发人员处理代码而存在，我建议您放弃为测试方法创建接口的想法——以前从未见过，现在抱歉刚才看到了。这些接口的存在只会妨碍您在代码中搜索对方法名称的引用，或者让您的 IDE 在您希望找到如何正确使用示例的任何方法上显示调用层次结构。不要以自己的方式行事。

在测试的情况下，因为它们是文档，所以我倾向于偏离 Java 中命名方法的通常模式。也就是说，我将放弃使用 camelCase 来支持 all_lowercase_separated_by_underscores，这通常看起来更容易阅读。因此，我将使用“should_do_something”或“ensure_whatever”，以便测试用例名称帮助我找到我可能正在寻找的东西。另外，我会较少关注测试方法，而更关注测试行为——我知道这听起来像分裂头发，但我就是这么想的。弄清楚类需要做什么并编写这些测试，然后使用 TDD 实现。如果我使用 TDD 或其近似值，我通常觉得不需要回填任何测试。 Jimmy 在保持您的代码专注和遵循 SRP 方面是完全正确的。

希望有帮助！

编辑：命名约定总是有争议的——只要选择一个适合你的。之前出现过here 和here。

【讨论】：