Question

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

我从未见过使用接口来定义您在测试中涵盖的测试用例。

例如

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

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

使用null param
检查该方法是否会为某个param的区域抛出运行时异常
检查该方法是否返回预期结果（正常情况）
检查不同的内容

在我们测试这些案例的项目中，人们只需创建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
...
}

Answer 1

由于开发人员测试本质上是文档并且为了方便开发人员处理代码而存在，我建议你不要考虑为测试方法创建接口 - 以前从未见过很遗憾刚刚看到它。这些接口的存在只能在您搜索代码以获取对方法名称的引用时使用，或者让IDE在您希望找到如何正确使用的示例的任何方法上显示调用层次结构。不要以自己的方式放东西。

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

希望有所帮助！

编辑：命名约定总是存在争议 - 只需选择一个适合您的命名约定。它之前出现here和here。

单元测试的测试用例

1 个答案: