验证是否调用了方法并中断执行/忽略以后的失败

Question

我有一个测试，我已经编写了我需要的大部分单元测试，但是有一个我想测试逻辑的第一位。只要调用了方法，我不在乎方法的其余部分会发生什么，但是由于缺乏进一步的模拟，SUT在NPE中失败，所以在我断言之前测试就失败了。

是否有一种明确的方法来断言调用了某个方法并忽略此后发生的所有异常？也许是在命中方法并在之后中止/通过测试时的某种阻塞行为？

我想我可以写的时候（mock.methodIAm感兴趣在（任何））.然后删除（新的运行时例外（“已验证！”）），然后简单地断言我得到了正确的异常（不过，它将被包装在另一个异常中）。这可能会起作用，但它有点不干净：模糊了我真正想要测试的内容。

@Test
public void should_load_using_filename_in_config() {
    loader = new OrgUnitLoader(config, dbSupport.mockServices);
    config = mock(TestConfiguration.class);
    /* further mocking of the config needed if I am not to get an NPE */

    when(dao.orgUnitsAreLoaded()).thenReturn(false);

    // call the actual method
    loader.loadOrgUnits();

    verify(config, times(1)).getString(ORG_UNIT_DATA_FILE);
}

例如，可以使用CountdownLatch吗？

Answer 1

由于您知道您的测试加载器/配置不完整，因此您希望该方法在某个时候失败。在您的测试中考虑它：

@Test
public void should_load_using_filename_in_config() {
    loader = new OrgUnitLoader(config, dbSupport.mockServices);
    config = mock(TestConfiguration.class);
    /* further mocking of the config needed if I am not to get an NPE */

    when(dao.orgUnitsAreLoaded()).thenReturn(false);

    try {
        // call the actual method
        loader.loadOrgUnits();
        Assert.fail("Should fail as config is incomplete.");
    } catch (NullPointerException e) {
        verify(config, times(1)).getString(ORG_UNIT_DATA_FILE);
    }

}

编辑（以下注释）

仅捕获预期的NPE排除其他异常。应该在dao之前抛出NPE吗。orgUnitsAreLoaded（）被调用verify（…）将失败。你会注意到的。

也许这不是很复杂，但它是非常简单和容易理解（吻）-甚至后来被其他人。

@see Junit 在等待和处理异常后断言某些内容

Answer 2

为什么不使用CompletableFuture，您可以使用一个无参数构造函数创建这个类的实例来表示将来的结果，将其分发给使用者，并在将来的某个时候使用complete方法完成它。使用者可以使用get方法阻止当前线程，直到提供此结果。

Answer 3

我想测试逻辑的第一部分。我不在乎方法的其余部分会发生什么

看起来你的测试代码没有通过单一责任模式。

您可以将该方法的独立部分提取为单独的方法，或者更好地提取为自己的Objects。结果，您当前的方法将成为一个组合方法，它使用一些逻辑非常小的依赖项，很容易测试。

有两个明显的缺点:

1. 然后，我需要打开SUT，将许多本来应该是私有的内部方法变成可以访问包的方法，以便能够对它们进行测试寡氟醚

关键是，有一个明显的需求，即独立于填充到当前方法中的实际业务逻辑来验证调度行为。这告诉我，这个分派行为是它自己的责任，应该与方法的其余部分分开。

在我看来，所有其他逻辑都属于其他类，而不仅仅是同一类中的单独方法。这是我们应该应用于类和方法的相同抽象级别原则的结果。这个新类确实将提供对其接口的包私有访问。

这种“紧密绑定”可能只存在于您的头脑中，因为您知道实际的实现。事实上，您需要分割代码进行测试，这表明代码没有您想象的那么严格。

我想在所有单元测试决策中都有一定的实用主义（仅测试代码，开放，…）。-oligofren

关于单元测试有一个非常简单的规则，可以避免所有“实用决策”的东西:

UnitTest不测试代码，UnitTest验证公共可观察行为，其中公共意味着：返回值和与依赖项的通信。

没有“务实决定”的余地。唯一的决定是:切割的预期行为是什么？