Проверка методов вызывает лямбду с помощью Mockito

Question

Я пытаюсь проверить и зафиксировать аргументы некоторых вызовов методов в лямбда-выражении следующим образом:

public Optional<UserDetails> findOne(String userName) {
    String selectStatement =
        "SELECT * FROM users WHERE userName = :userName;";

    return jdbi.withHandle(handle -> handle
            .createQuery(selectStatement)
            .bind("userName", userName)
            .map(new UserDetailsMapper())
            .findOne());
  }

jdbi.withHandle() принимает аргумент HandleCallBack, который выглядит следующим образом:

public interface HandleCallback<T, X extends Exception> {
  T withHandle(Handle handle) throws X;
}

Например, я хочу проверить, что .bind() был вызван с "userName" и передана в userName строка аргумента из моего findOne метода.

Это делает Я чувствую, что я тестирую модуль Jdbi, а не свой собственный класс, но я чувствую, что аргументы .createQuery() .bind() и .map() должны быть протестированы, поскольку они могут быть случайно изменены разработчиком.

Подход, который я сейчас выбрал, заключается в создании базы данных в памяти и проверке того, что фактически возвращается, но это больше похоже на интеграционный тест, чем на модульный тест. Мне также не важно, что на самом деле возвращает метод Jdbi .withHandle(), так как я бы по сути проверял библиотеку на этом этапе.

Насколько я понимаю, я должен проводить модульное тестирование аргументов, передаваемых .withHandle() (в данном случае лямбда-выражением), что я и пытаюсь сделать здесь.

ближе всего я переместил логи c в ссылку на метод, но это не сработает, поскольку userName передается в мой метод findOne() и затем используется внутри лямбды.

У меня есть также безрезультатно поигрался с doAnswer в Mockito.

Я могу только думать о создании нового класса с вспомогательными методами, которые возвращают userName, selectStatement, et c и проверяют, что они вызван, но он кажется ненужным и будет добавлен просто для обеспечения тестируемости.

Answer 1

Лямбда-выражение является частью реализации метода findOne. Итак, вы должны проверить это как часть тестирования findOne. Но он не выполняется при вызове findOne. Таким образом, чтобы иметь возможность протестировать его, выполнить findOne и выполнить проверки и подтверждения этого будет недостаточно.

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

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