Убедитесь, что метод был вызван и прервал выполнение/игнорировал более поздние сбои

Я хочу проверить первые биты логики. Мне все равно, что происходит в остальной части метода

Похоже, ваш тестируемый код не соответствует шаблону единой ответственности.

Вы можете выделить независимые части этого метода в отдельные методы или, что еще лучше, в собственные объекты. В результате ваш текущий метод станет составленным методом, использующим некоторые зависимости с очень небольшой логикой, которую будет легко протестировать.

есть два очевидных минуса:

1. Затем мне нужно будет открыть SUT, превратив множество внутренних методов, которые, естественно, должны быть закрытыми, в методы с пакетным доступом, чтобы иметь возможность их протестировать. – олигофрен

Дело в том, что существует очевидная необходимость проверять поведение отправки независимо от фактической бизнес-логики, заложенной в текущий метод. Это говорит мне о том, что это поведение отправки является собственной ответственностью, которая должна быть отделена от остального или метода.

Мне кажется, что вся остальная логика принадлежит другим классам, а не только отдельным методам в том же классе. Это следствие принципа Один и тот же уровень абстракции, который мы должны применять как к классам, так и к методам. Эти новые классы действительно обеспечивают по крайней мере package private доступ к своему интерфейсу.

2. Я был бы очень сильно привязан к внутренностям ТРИ, но, наверное, я уже это делаю… — олигофрен

Эта «жесткая привязка» может существовать только в вашей голове, зная фактическую реализацию. Тот факт, что вам нужно разделить код для тестирования, показывает, что код менее жестко ограничен, как вы думаете.

Я предполагаю, что во всех решениях по модульному тестированию присутствует определенный прагматизм (код только для тестирования, открытие,...). – олигофрен

Существует довольно простое правило юнит-тестирования, которое позволяет избежать всех этих «прагматических решений»:

UnitTest не тестирует код, UnitTest проверяет общедоступное наблюдаемое поведение, где общедоступное означает: возвращаемые значения и < em>связь с зависимостями.

Здесь нет места «прагматичным решениям». Единственное решение: каково ожидаемое поведение CUT?

Почему вы не используете CompletableFuture, вы можете создать экземпляр этого класса с конструктором без аргументов для представления некоторого будущего результата, передать его потребителям и завершить его в какое-то время в будущем, используя метод complete. Потребители могут использовать метод get для блокировки текущего потока до тех пор, пока не будет предоставлен этот результат.

Поскольку вы знаете, что ваш тестовый загрузчик/конфигурация неполный, вы ожидаете, что метод в какой-то момент не сработает. Учтите это в своем тесте:

@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 исключает другие исключения. Если NPE будет выброшен до вызова dao.orgUnitsAreLoaded(), verify(...) потерпит неудачу. Вы это заметите.

Может быть, это не очень сложно, но очень просто и легко (KISS) понять - даже позже другим.

@see Junit утверждает что-то после ожидания и обработки исключения