Gdzie należy umieścić testy jednostkowe podczas migracji projektu Java 8 do Jigsaw

Question

Obecnie testuję, aby przeprowadzić migrację aplikacji Java 8 do Javy 9/Jigsaw, używając jdk-9 + 149.

Projekt został rozplanowany w standardowej strukturze katalogów Maven, to znaczy mający src/main/java, src/test/java itp

Jak tylko dodać module-info.java do src/main/java, Maven-compiler-plugin zawiedzie rzuca NullPointerException. Dzieje się tak, ponieważ spodziewa się znaleźć informacje o module dla katalogu test. Tak więc, o ile widzę, opcje są następujące:

• utrzymywać klasy testowe w oddzielnym module, co oznacza, że ​​mogą uzyskać dostęp tylko do wyeksportowanych pakietów modułu głównego.
• przenieść klasy testowe do modułu głównego, wraz ze źródłami, co oznacza, że ​​główny moduł wymaga zależności testowych.

Oczywiście żadna z tych opcji nie wydaje się pożądana, dlatego zakładam, że istnieje zalecany sposób testowania modułów Jigsaw w projekcie Maven. Nie mogłem znaleźć ani zaleceń, ani przykładów.

EDIT: Dodawanie pewne informacje, że nie uważa istotne podczas księgowania pytanie (przepraszam)

• the NullPointerException I ran into
• Maven 3.3.9
• Maven-compiler-plugin 3.6.0
• konfiguracja źródła i celu: 9

Answer 1

Obsługa Maven dla Javy 9 w ogóle, a testy w szczególności wciąż są pod Rozwój - wiele rzeczy działa, ale inne nie. Nie widząc śladu stosu dla NPE, jest to oczywiście spekulacja, ale zakładam, że jesteś ran into this error.

Bardziej ogólnie, wciąż trwa dyskusja nad tym, jak dokładnie testy jednostkowe będą działać z Jigsaw - nawet on the Jigsaw mailing list.

Oto moja opinia w tej sprawie:

1. Jak można zauważyć, putting testy do osobnego modułu oznaczałoby, że tylko typy publiczne w eksportowanych pakietów byłyby sprawdzalne, co na pewno nie jest mało. Może istnieć obejście, ale te wymagają edycji deklaracji modułu (kod źródłowy; module-info.java) lub deskryptora (kod bajtowy, module-info.class) w locie lub dodania tonów flag linii poleceń --add-exports do poleceń javac i java kompilujących i uruchamiających testy . Żadne z nich nie brzmi szczególnie zabawnie, szczególnie jeśli chcesz to zrobić ręcznie.

2. Przenoszenie testów do drzewa źródłowego jest również złym pomysłem z oczywistych powodów, między innymi to, że utworzenie JARa bez testów wymagałoby wtedy dużo manipulowania.

3. Inną opcją jest użycie opcji --patch-module, która umożliwia dodawanie plików class lub zawartości JAR do istniejącego modułu.W ten sposób krok testCompile może utworzyć plik JAR zawierający pliki testowe źródła i. Niestety, jeśli nie manipuluje deklaracją/opisem modułu jak opisano powyżej, wynikowy plik JAR nie może zostać wykonany bez dodawania krawędzi odczytu z java --add-reads dla zależności testowych. Nadal, lepiej niż powyżej.

4. Jako środek ostateczny, istnieją sposoby, aby produkcja JAR traktować jak zwykły JAR zamiast jako moduł. Najłatwiej byłoby prawdopodobnie zrzucić go na ścieżce klasy razem z testowym JARem. W ten sposób wszystko działa tak, jak w Javie < 9. Niestety to złamie kod, który wykorzystuje funkcje przy założeniu, że znajduje się wewnątrz nazwanego modułu (np. Pewne rodzaje interakcji z interfejsem API do refleksji).

Osobiście uważam 3. za najlepszą spośród powyższych opcji. Nie wymagałoby to żadnych zmian w układzie projektu i jedynie względnie niewielkich dodatków do poleceń javac i java.

Answer 2

Musisz przynajmniej używać programu maven-compiler-plugin 3.6.0, aby mieć wsparcie dla układanki. Jednak od czasu kompilacji +148 zmieniła się struktura binarna pliku klasy, więc wtyczka nie może wyodrębnić nazwy modulu jak poprzednio (nazwa modułowa jest wymagana, aby móc skompilować testy). Pracuję nad poprawką, ale prawdopodobnie zależę od nowej wersji ASM.

AKTUALIZACJA: maven-compiler-plugin-3.6.1 został zwolniony, więc wsparcie dla układanki zostało przywrócone.

Answer 3

Jak już suggested here korzystając z zaktualizowaną wersję maven-compiler-plugin: 3.7.0 powinna pomóc rozwiązać ten problem: -

<plugins> 
    <plugin> 
     <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-compiler-plugin</artifactId> 
     <version>3.7.0</version> 
     <configuration> 
      <source>9</source> 
      <target>9</target> 
      <compilerArgument>-Xlint:all</compilerArgument> 
     </configuration> 
    </plugin> 
</plugins> 

Gdzie można umieścić swoje testy jednostkowe w tym samym katalogu, co kiedyś było przed modularyzacją. Oto sample project ode mnie, który jest oparty na JDK9 i Maven3 +. Projekt opiera się na strukturze katalogów jak przedstawiony na zrzucie ekranu: -

i post to wszystko co musisz zrobić, to wykonać testy za pomocą polecenia:

mvn test 

z katalogu głównego projekt, aby znaleźć testy, byłby wykonywany jak zwykle.