Antichesse (o ^ω^ o)
Le paramètre --illegal-access=permit est nécessaire à cause des modules de Java 9 qui font qu'une classe d'un package A dans un jar A ne peut plus accéder aux classes non exportées d'un package B dans un jar B.
Or Surefire procédant au scanne du classpath pour charger via API réflexion toutes les classes suffixées par Test et y exécuter toutes les méthodes annotées par @Test, il viole alors l'accès restreint des modules de notre code. Donc mécaniquement, et si l'on veut exécuter des TU, il faut lever la restriction via ce paramètre.
N.B : ce problème ne touche pas que Surefire mais également tous les frameworks s'appuyant sur l'API réflexion (coucou Spring Boot).
Je résume, si vos tests unitaires sont deux à deux distincts, s'ils n'engendre pas de conflits lors de leur exécution en parallèle (donc il faut dissocier les TU des TI qui quant à eux s'appuient sur l'injection de dépendances) alors vous pouvez dire à Surefire d'exécuter en parallèle autant de TEST que vous avez de Thread CPU de disponibles.
Après un benchmark succinct, j'ai divisé par 5 le temps d'exécution de mes tests sur un 4 cœurs physiques et 8 cœurs logiques via la technologique HT (Hyper-Threading chez Intel / Hyper-Transport chez AMD).
Voici comment faire :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M3</version>
<configuration>
<forkCount>1C</forkCount> <!-- C'est la même commande que pour Maven, 1 thread / CPU -->
<reuseForks>true</reuseForks>
</plugin>Si vous configurer Surefire avec certaines options, il ne vous sera plus possible de produire des rapports avec JaCoCo (le fichier jacoco.exec dédié à l'agent JaCoCo ne sera plus produit).
Ce poste explique comment résoudre le problème en remplaçant les configurations de Surefire
et