java - 关于单元测试结构的思考

Question

我正在考虑如何为我的项目编写测试。目前，测试结构如下:

RealClass 
{ 
      method1; 
      method2; 
      ...
}

和完全相同的测试类结构:

TestClass {
   testMethod1; 
   testMethod2; 
   ...
 }

但是，我不喜欢它，因为我在一个测试方法中放入了太多的测试用例......

也许我应该使用这样的结构:

TestClass {
   testMethod1Opt1; 
   testMethod1Opt2; 
   ... 
   testMethod2Opt1; 
   ...}

您如何编写单元测试？

我的测试代码示例:(非常简单的测试)

public void testIsAppUser() {
    // My (Artem`s Zinnatullin) uId
    final long artemZinnatullinUId = 172672179;

    try {
        assertTrue(usersApi.isAppUser(artemZinnatullinUId));
    } catch (Exception e) {
        fail(e.getMessage());
    }

    // Pavel`s Durov uId
    final long durovUId = 1;

    try {
        assertFalse(usersApi.isAppUser(durovUId));
    } catch (Exception e) {
        fail(e.getMessage());
    }

    // By default uId == current user`s (who has authorized) uId 
    try {
        assertTrue(usersApi.isAppUser(null));
    } catch (Exception e) {
        fail(e.getMessage());
    }
}

我在想什么:

public void testIsAppUser1() {
    // My (Artem`s Zinnatullin) uId
    final long artemZinnatullinUId = 172672179;

    try {
        assertTrue(usersApi.isAppUser(artemZinnatullinUId));
    } catch (Exception e) {
        fail(e.getMessage());
    }
}

public void testIsAppUser2() {
    // Pavel`s Durov uId
    final long durovUId = 1;

    try {
        assertFalse(usersApi.isAppUser(durovUId));
    } catch (Exception e) {
        fail(e.getMessage());
    }
}

public void testIsAppUser3() {
    // By default uId == current user`s (who has authorized) uId
    try {
        assertTrue(usersApi.isAppUser(null));
    } catch (Exception e) {
        fail(e.getMessage());
    }
}

请给我建议。

Answer 1

评论:

1. 只需将 throws Exception 添加到测试方法即可，而不是 try{} catch(){ failure() }。 JUnit 将自动为您测试失败并保留堆栈跟踪。这将使错误修复变得更加容易。

2. 创建小型测试方法。这就产生了一个名字问题:如何想出很多好名字？这里的解决方案是根据逻辑测试的内容来命名测试，而不是根据它调用的方法来命名。

   如果您想查看调用了哪些方法，请使用代码覆盖率工具，例如 JaCoCo .

   因此第一个测试应该称为testIsArtemsZinnatullinAppUser()。作为指导:每当您觉得需要注释来解释测试的作用时，测试名称就是错误的。使用您在评论中编写的任何内容来创建测试名称。

您应该进行较小测试的原因是 JUnit 因第一个问题而停止。因此，如果一个测试用例中有 20 个测试，而第 3 个测试失败，则 17 个测试将无法运行。但这 17 项测试可能包含有值(value)的信息，有助于找出问题所在。

如果它们都成功，那么这可能是一个特定的问题。如果许多测试失败，则问题一定出在共享代码中。