Как открыть пакеты и требовать зависимости от модулей области тестирования только для тестирования JUnit - PullRequest
Новая
       38

Как открыть пакеты и требовать зависимости от модулей области тестирования только для тестирования JUnit

0 голосов
/ 07 января 2019

Я перевожу проект jar из java 10, используя classpath, в java 11, используя java 9 jigsaw-модули. Есть тесты JUnit5 для проекта. Зависимости теста предоставляются в области тестирования maven. Как сделать все пакеты открытыми для тестирования, но не открытыми, когда модуль используется другим проектом?

Проект jar просто предоставляет несколько классов (например, служебный проект) для других проектов (поэтому основной класс не требуется).

Проект получил 5 пакетов в / src / main / java / a / b / c / . 2 из них должны быть доступны для проектов, использующих этот jar. Остальные 3 предназначены только для внутреннего использования (используются доступными). Тесты расположены по адресу / src / test / java / a / b / c / . Эти тесты имеют зависимости (JUnit, mockito, junt-params), предоставленные в области тестирования, поскольку тесты не относятся к проектам, использующим этот jar 

<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-params</artifactId>
<version>${junit.version}</version>
<scope>test</scope>
</dependency>

Я предоставил module-info.java в / src / main / java / : 

module moduleName {

requires java.base;

exports a.b.c.package1;
exports a.b.c.package3;
}

так что теперь публичные классы в пакетах 1 и 3 должны быть доступны для других проектов, как и ожидалось (я пока не смог проверить это).

Запуск тестов теперь приводит к java.lang.reflect.InaccessibleObjectException: невозможно сделать доступным a.b.c.package1.collections.SomeTest (): moduleName не «открывает a.b.c.package1» для неназванного модуля @ 6a84a97d

когда я открываю пакеты (при открывается ) все работает гладко. Но теперь все пакеты теперь открыты. Я ожидаю, что пакеты 2, 4 и 5 будут доступны только во время тестирования, а 1 и 3 не должны быть открыты для размышления (поэтому только для экспорта).

Я пришел к выводу, что поскольку maven говорит мне неназванный модуль @ 6a84a97d , это может быть модуль, созданный для тестирования. Это заставило меня попробовать добавить module-info.java в / src / test / java / для тестирования. 

module moduleNameTest {
requires moduleName; // the code to test
requires java.base;  // java.base could be transient on moduleName

// test dependencies
requires org.junit.jupiter.api;
requires org.junit.jupiter.params;
}

сейчас maven (3.5.4) заявляет: 

src/test/java/module-info.java:[3,20] module not found: moduleName
src/test/java/module-info.java:[4,31] module not found: org.junit.jupiter.api
src/test/java/module-info.java:[5,31] module not found: org.junit.jupiter.params

Технология:

  • Java OpenJDK 11
  • мвн 3.5.4
  • JUnit 5.3.0
  • Surefire Plugin 3.0.0-M3
  • mockito 2.21.0

Как указывалось ранее, я ожидаю, что пакеты 2, 4 и 5 будут доступны только во время тестирования и запуска тестов на сборку фляги с maven. Пакеты 1 и 3 должны быть экспортированы для использования в других проектах, но не открыты для отражения (поэтому только экспортированные не открыты).

Если вам нужна дополнительная информация, не стесняйтесь спрашивать.

Заранее спасибо

Kevin

1 Ответ

0 голосов
/ 07 января 2019

«Добро пожаловать на тестирование в модульном мире», Кевин.

Я собрал блог на эту тему здесь: https://github.com/sormuras/testing-in-the-modular-world

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

Полагаю, вы на правильном пути ... может быть, Surefire поступает неправильно? Хотите дать https://github.com/sormuras/junit-platform-maven-plugin Я написал выстрел? Этот плагин поддерживает тестирование черного и белого ящиков из коробки. Особенно этот плагин светится, когда вы предоставляете дескриптор тестового модуля test/java/module-info.java.

Смотрите эту «картинку», чтобы узнать, как организовать модульные тесты без касания основного дескриптора модуля:

src ├── main │ └── java │ ├── foo │ │ ├── PackageFoo.java │ │ └── PublicFoo.java │ └── module-info.java <------------------ module foo { exports foo; } ├── test │ └── java .--- open module foo { │ ├── foo / exports foo; │ │ └── PackageFooTests.java / requires org.junit.jupiter.api; │ └── module-info.[java|test] <----< } └── it \ └── bar °---- --add-reads └── src foo=org.junit.jupiter.api └── test --add-opens └── java foo/foo=org.junit.platform.commons ├── bar │ └── PublicFooTests.java └── module-info.java <------ open module bar { requires foo; requires org.junit.jupiter.api; }

Этот шаблон также должен быть легко адаптирован к вашим настройкам.

Смежный вопрос: Как вы организуете тесты в модульном проекте Java?

...