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

Это мой базовый модуль, которому нужны реализации интерфейсов, определенных в пакете 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 возвращает null). Как я могу протестировать модули поставщика услуг с помощью Junit 5. Или есть какая-либо альтернатива Junit, которая позволяет нам создавать тестовые модули (модульный тестовый API), который объявляет "использует myspi.MyProvider" в информации о модуле и отлично работает с getMyProviders ( )?


person aekarahan    schedule 04.09.2018    source источник
comment
Это стоит посмотреть stackoverflow.com/questions/52110023/, ответ Сормураса показывает, как выглядит мир тестирования с модулями.   -  person Naman    schedule 04.09.2018
comment
Я уже могу писать тесты черного ящика для других модулей и получать доступ к их экспортированным пакетам. Здесь проблема заключается в написании тестов для экспорта поставщика услуг, как я описал выше. Не могу загрузить сервис в тестах. Как бы то ни было, я сейчас читаю ответ Сормураса, пытаясь найти ключ к разгадке. Возможно, мне стоит переместить реализацию как простой старый JAR без информации о модуле, протестировать этот jar как простую библиотеку и использовать эту библиотеку для создания модуля поставщика услуг. Но это уродливое решение.   -  person aekarahan    schedule 04.09.2018
comment
Почему бы вам просто не создать экземпляр поставщика с new MyProviderImpl()? Вы хотите протестировать реализацию или конфигурацию?   -  person johanneslink    schedule 04.09.2018
comment
johanneslink Потому что будет несколько MyProviderImpl (). Они могут предлагать разный контент данных, используя один и тот же API, и приложение позволяет переключаться между сторонними поставщиками. Конечно, я могу протестировать свою единственную фиктивную реализацию, но я уже выполнил этот тест до Java 9. После модуляции я хочу проверить, что мой базовый модуль найдет любого стороннего поставщика и привяжет их к моему приложению с помощью служебных классов базового модуля, поэтому я все они могут использоваться для тестирования остальных API базового модуля. Фактически, я хочу протестировать остальную часть базового модуля с контентом, полученным от провайдеров.   -  person aekarahan    schedule 04.09.2018


Ответы (2)


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

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

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

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

Примеры

Справочная информация и другие ресурсы

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

person Sormuras    schedule 04.09.2018
comment
Спасибо, Сормурас. Я уже просматривал и читал ссылки на ваши ссылки в приведенном выше комментарии к нулевому указателю. Сегодня вечером я попытаюсь открыть тестовый модуль, как показано в одной из ваших ссылок и в книге «Модульность Java 9», Сандер Мак и Пол Баккер. В этом контексте я бы хотел, чтобы вы дали мне более короткий ответ, чтобы запустить метод getMyProviders (), описанный выше. Он нужен мне для тестирования остальных пакетов в моем базовом модуле. Никаких тестов WhiteBox не пишу, потому что они хрупкие. - person aekarahan; 04.09.2018

РЕШЕНО!

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

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

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

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

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

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

Я хотел бы поблагодарить всех откликнувшихся участников.

person aekarahan    schedule 05.09.2018
comment
Рад, что вы разобрались! Я писал о тестировании в модульном мире здесь: sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world - person Sormuras; 12.09.2018