java - 如何验证多个 JUnit 4 测试的整体执行情况？

Question

期望:“测试中的测试”

想象一下，在测试类完成其所有测试后可以执行一些额外的“健全性检查”，以指示整个测试执行是否成功执行。最终的健全性检查可能会使用有关测试的一些汇总信息。就像一个粗略的例子:对共享方法的调用次数进行计数，如果在所有测试完成后计数不高于某个最小预期阈值，那么即使所有单独的测试都通过，也很明显出现了问题。

我所描述的可能处于最佳实践的某些“灰色区域”，因为虽然它确实违反了原子单元测试的原则，但最终的健全性检查实际上并没有测试正在测试的类;相反，它正在检查整个测试执行是否成功:可以说是“测试的测试”。这是关于测试本身的附加逻辑。

这个解决方案似乎很糟糕

完成这种“测试的测试”的一种方法是将健全性检查放在静态 @AfterClass 方法中。如果检查失败，可以调用 Assert.fail()，它实际上可以工作(令人惊讶的是，因为我认为它只能从用 @Test 注解的方法中调用，它本质上必须是实例方法，而不是静态的):

public class MyTest {

   [...]

    @AfterClass
    public static void testSufficientCount() {
        if (MyTest.counterVariable < MIN_COUNT) {
            Assert.fail("This fail call actually works. Wow.");
        }
    }

}

这个解决方案是一个拼凑的原因有很多:

• 假设总共有 N 个测试(其中“测试”是用 @Test 注解的实例方法)。当 @AfterClass 中未调用 Assert.fail() 时，IDE 总共报告 N 次测试，正如预期的那样。但是，当在 @AfterClass 中调用 Assert.fail() 时，IDE 总共报告了 N + 1 次测试(额外的一次测试)是静态 @AfterClass 方法)。附加静态方法未使用@Test注释，因此不应将其视为测试。此外，测试总数不应该是某些测试通过或失败的函数。
• 根据定义，@AfterClass 方法是静态的。因此，只能访问静态成员。这对我的具体情况提出了一个问题；我将不再详细说明这一点，因为解释超出了问题的范围，但基本上，如果仅使用实例成员将是最可取的。
• [还有其他原因...]

有更好的方法吗？

有没有一种方法可以实现这种被认为是良好且常见的做法的“测试的测试”？ JUnit 4 是否支持添加某种逻辑来确保类中的一组单元测试正确执行(如果没有，则会以某种方式失败)？我称之为“测试的测试”的东西有名字吗？

Answer 1

关于可变数量的测试

我认为没有有效的解决方案......

关于静态字段

我尝试按照你的例子，如果我理解得很好的话，结合 Verifier , TestRule和 ClassRule可以仅使用测试类的实例字段

这是我从中获取提示的代码:

public class ATest {

    public int countVariable = 0;

    private static class MyVerifier extends Verifier {

        public int count = 0;

        @Override
        protected void verify() throws Throwable {
            assertTrue(count < 1); // cause new failed test
        //  assertTrue(count >= 1);  // it's all ok
        }

    }

    @ClassRule
    public static MyVerifier v = new MyVerifier();

    private class MyRule implements TestRule {

        ATest a;
        MyVerifier v;

        public MyRule(ATest a, MyVerifier v) {
            this.a = a;
            this.v = v;
        }

        @Override
        public Statement apply(Statement base, Description description) {
            try {

                base.evaluate();
                this.v.count = a.countVariable;
            } catch (Throwable ex) {
                Logger.getLogger(ATest.class.getName()).log(Level.SEVERE, null, ex);
            }
            return base;
        }

    }

    @Rule
    public MyRule rule = new MyRule(this, v);

    @org.junit.Test
    public void testSomeMethod() {
        countVariable++; // modifies instance counter
        assertTrue(true);
    }

    @org.junit.Test
    public void testSomeMethod2() {
        countVariable++; // modifies instance counter
        assertTrue(true);
    }

}

话虽如此

“测试的测试”不被认为是一种常见的良好实践，因为如您所知，它至少违反了第一条规则的五个原则中的两个(请参阅Cleean code from Uncle Bob Martin):测试必须是

• F:快
• 我:独立
• R:可重复
• S: self 验证
• T:及时(与 TDD 实践相关)