TestNG testet die Ausführung gegen JDK 9-Modul verursacht InaccessibleObjectException

8

Ich versuche, die folgende Bibliothek in Java 9-Modul umzuwandeln: Ссылка

Dieser Anleitung folgend: Ссылка

Nach einigen Manipulationen und Refactoring (konnte lombok Probleme nicht verwalten, so nur vorübergehend entfernt es), habe ich die folgenden module-info.java :

%Vor%

Und es kompiliert / baut sogar im Falle des Überspringens von Tests. Wenn ich versuche, eine test Aufgabe auszuführen, erhalte ich die folgende Ausnahme:

%Vor%

Es scheint mir etwas verwirrend, da io.github.sskorol.testcases ein Teil von src / test / java ist und es kein Modul gibt - info für Tests. Also kann ich dieses Paket nicht nach TestNG exportieren. Nehmen Sie an, dass die Ursache in einer TestNG-Reflektion innerhalb von ObjectFactoryImpl gegen Testklassen liegt.

Hat jemand eine Idee, wie man es umgehen kann?

Umgebung: JDK 9 (Build 9 + 181), Gradle 4.1, TestNG 6.11

    
Sergey Korol 14.08.2017, 11:25
quelle

3 Antworten

5
  

Gehen Sie davon aus, dass die Ursache in einer TestNG-Reflektion in ObjectFactoryImpl gegen Testklassen verwendet wird.

Es ist eine von zwei Ursachen, ja. Der andere ist, dass Gradle offensichtlich deine Tests als Modul durchführt. Wie Sie feststellen, gibt es keinen Moduldeskriptor für Ihre Tests. Gradle kann --patch-module , um die Tests zu dem Modul hinzuzufügen, das den Produktionscode enthält.

Diese Frage und Antwort enthält viele Hintergrundinformationen und mögliche Korrekturen. Als kurzfristige Lösung empfehle ich, opens io.github.sskorol.testcases zum Moduldeskriptor des Produktionscodes hinzuzufügen. Nach seinem Namen zu urteilen, würde ich vermuten, dass es noch kein solches Paket gibt, also müssten Sie entweder eine Dummy-Klasse umbenennen oder hinzufügen (ich würde die erste bevorzugen).

Ich würde dieses Problem auch einer Mailingliste oder einem Bugtracker von Gradle stellen. Wenn wir nicht etwas übersehen haben (durchaus möglich), ist das Verhalten von Gradle sehr unglücklich, da es erforderlich wäre, den Moduldeskriptor des Produktionscodes an die Anforderungen des Testcodes anzupassen.

    
Nicolai 14.08.2017, 12:11
quelle
1

Wenn sich die Tests im gleichen Paket wie das zu testende Modul befinden, müssen sie kompiliert werden (mit --patch-module ), so dass sie so kompiliert werden, als ob sie Teil des Moduls wären. Die Verweise auf TestNG-Typen in den Tests bedeutet, dass auch --add-reads io.github.sskorol=testng benötigt wird.

Laufen ist ähnlich. Die Tests müssen "so als ob" in Modul io.github.sskorol ausgeführt werden. Dies bedeutet, dass mit:

ausgeführt wird %Vor%

Zusätzlich müssen Sie möglicherweise die Pakete mit den Tests zu TestNG exportieren oder öffnen. Dies hängt davon ab, ob die Testklassen und -methoden in einem exportierten Paket öffentlich sind. Um das Scannen zu vermeiden, öffnen Sie am einfachsten alle Pakete, die Tests enthalten, an TestNG, z. B.

%Vor%

( .internal ist nur ein Füllelement für ein nicht exportiertes Paket im Modul)

All dies mag kompliziert aussehen, aber es ist etwas, was das Maven Surefire-Plugin und auch Gradle tun sollten.

    
Alan Bateman 31.08.2017 08:52
quelle
0

Hat einige Tricks von @AlanBateman vorgeschlagen, die mir eine gültige Richtung gegeben haben.

Schließlich habe ich folgende Konfiguration gefunden:

module-info.java

%Vor%

build.gradle

%Vor%

Sowohl testng als auch joor benötigten Zugriff auf meine Testpakete. Also --add-opens flag hat den Trick gemacht. streamex Modul hatte auch Bedenken beim Zugriff auf java.base Pakete.

Beachten Sie, dass ich im Vergleich zum ursprünglichen Java 8-Code lombok und aspectj Abhängigkeiten entfernen musste, da ich nicht alle Probleme nach der Migration vollständig lösen konnte .

Ein anderes Problem, mit dem ich konfrontiert war, war das SPI-Testen. Laut den Dokumenten, die ich gelesen habe, sollten in Java 9 SPI-Implementierungen in module-info.java statt in META-INF/services aufgeführt sein. Es scheint jedoch keine Lösung zu sein, wenn sich die Implementierungsklasse in einem der Pakete test befindet, da auch test kein Modul ist. Ich frage mich nur, ob es eine jvmflag gibt, die provides ... with ... -Syntax ersetzt, und den gleichen Trick wie mit --add-opens . Irgendwelche Gedanken würden geschätzt werden.

Vollständige Implementierung, die modifiziert wurde, um Java 9 zu unterstützen, könnte hier .

    
Sergey Korol 17.09.2017 17:51
quelle

Tags und Links