Question

我有以下JUnit测试。我正在测试的方法很简单，它只接收一个数字并返回一个带有除数的List。我不想多次重复测试代码，所以我创建了一个辅助方法，testDivisorsAux：

@Test
public final void testDivisors() {
    testDivisorsAux(1, new int[] { 1 });
    testDivisorsAux(6, new int[] { 1, 2, 3, 6 });
    testDivisorsAux(0, new int[] { });
    ...
}

private final void testDivisorsAux(final int number, final int[] expected) {
    List<Integer> divisors = Util.divisors(number);
    assertSame(divisors.size(), expected.length);
    for (int i : expected) {
        assertTrue(divisors.contains(i));
    }
}

一切正常，我只是想知道...... 这是一种不好的做法吗？我应该以不同的方式编写测试吗？也许将所有代码保留在“@Test方法”中？

PMD告诉我 JUnit测试应该包括assert（）或者fail（）（对于第一种方法），而执行测试的 JUnit 4测试应该使用@Test注释< / em>（对于第二个）。我知道PMD只使用正则表达式（好吧，实际上是XPath）来确定我打破的规则...所以我倾向于认为它只是一个“误报”警告。但无论如何，我想知道我做错了什么。（公寓写作测试的时间比测试方法长4倍）。

当我在寻找与此类似的问题时，我发现了一些名为参数化测试的东西......但似乎它面向更大的场景，不是吗？

Answer 1

我个人认为是这样做的好习惯。存在一个很小的危险，即走得太远并构建大量代码来进行测试，在这种情况下，您应该重新考虑您正在测试的东西的设计。你真的不想编写测试来测试你的测试，但你给出的例子似乎很好，这意味着你的测试用例要简单得多。

我没有使用PMD，我个人会尝试将其配置为插入这些警告。如果他们担心你，你可以改变你的代码来摆脱它们。我的猜测是第二个警告是因为你的辅助方法以单词test开头。在junit3中，所有以test开头的方法都是测试。为什么不将方法testDivisorsAux重命名为assertDivisors - 也许有一个以assert开头的方法也有助于第一个警告。

Answer 2

正如Adam Butler建议的那样，使用以assert开头的方法将解决此警告。

因此，在您的情况下，将testDivisorsAux重命名为assertDivisorsAux将修复它。

另请参阅http://pmd.sourceforge.net/pmd-4.3.0/xref/net/sourceforge/pmd/rules/junit/JUnitTestsShouldContainAsserts.html以了解检查规则的代码。

我应该在JUnit中拆分重用方法吗？

2 个答案: