Как я могу протестировать модуль реализации поставщика услуг с Junit 5? - PullRequest
Новая
       52

Как я могу протестировать модуль реализации поставщика услуг с Junit 5?

0 голосов
/ 04 сентября 2018

Это мой базовый модуль, которому нужны реализации интерфейсов, определенных в пакете myspi. Различные провайдеры могут предлагать реализации MyProvider. Базовый модуль использует их через реализацию интерфейса myspi.MyProvider. 

module base {
    exports myspi;
    uses myspi.MyProvider;
}

Это мой пример модуля реализации, который предоставляет реализацию MyProvider с MyProviderImpl 

module myspi.provider {
    provides myspi.MyProvider with myspi.provider.MyProviderImpl;
}

Все это прекрасно работает, когда я загружаю реализации в базовый модуль, с 

public static List<MyProvider> getMyProviders() {
        var myProviders = new ArrayList<MyProvider>();
        for (MyProvider myProvider : ServiceLoader.<MyProvider>load(MyProvider.class)) {
            myProviders.add(myProvider);
        }
        return myProviders;
    }

Но тот же код возвращает пустой список в тестовом коде Junit 5 (ServiceLoader возвращает ноль). Как я могу протестировать модули поставщика услуг с помощью Junit 5. Или есть ли альтернатива Junit, которая позволяет нам создавать тестовые модули (модульный тестовый API), который объявляет «использует myspi.MyProvider» в информации о модуле и прекрасно работает с getMyProviders ( )

Ответы [ 2 ]

0 голосов
/ 05 сентября 2018

РЕШИТЬ!

Я удалил Junit из class-path to module-path, а также удалил все компоненты совместимости Junit 4, такие как RunWith () и т. Д., И сделал мой тест чистым тестом Junit 5.

Я добавил модуль-info.java (Junit 5 не требует открытого модуля, хотя книги говорят об обратном)

После того, как я тестировал модуль, я обнаружил, что он все еще не выполняет вещи ServiceLoader. Тогда я сам начал искать неисправность.

И я нашел это! Запуск компонента ServiceLoader в базовом модуле был возможен, поскольку базовый модуль ссылается на экспортированный файл myProvider.jar, который, в свою очередь, обращается к файлу myProvider-config.properties в том же каталоге. Без этого конфигурационного файла myProvider не может работать должным образом.

С другой стороны, проблемный тестовый модуль ссылался на проект eclipse myProvider вместо экспортированного файла .jar и, следовательно, не смог найти его файл конфигурации и завершил работу. Я перенес этот файл конфигурации из Netbeans в Eclipse, просто скопировав его в тот же каталог. Таким образом, отсутствующий файл конфигурации был проблемой.

Изменяя настройки проекта, я мог запускать тесты без сбоев.

Я хотел бы поблагодарить всех авторов, которые ответили.

0 голосов
/ 04 сентября 2018

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

Тестирование черного ящика легко.

Тестирование белого ящика в модульном мире, то есть тестирование защищенных и пакетных закрытых членов в модуле, довольно сложно. Для этого есть как минимум два способа: а) использовать параметры командной строки java для настройки системы модулей Java при запуске теста или б) смешать основные источники с test источниками при компиляции время и поддерживать выделенный module-info.java в ваших тестовых источниках.

Пожалуйста, перейдите по ссылкам на блоги и примеры, размещенные на Как создать модульную сборку с jdk> 1.8 Вот выдержка для удобства:

Примеры

Фон и другие ресурсы

И ожидайте, что большинство IDE также не поддержат вас. На данный момент.

...