-
Notifications
You must be signed in to change notification settings - Fork 300
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance: archunit-junit5 may scan complete JDK for @ArchTest
#1316
Comments
Thanks for reporting this! I'm gonna take a look... |
Just out of curiosity, what's the use of a module without any |
I think the reason ArchUnit scans so much is because it has some pretty aggressive scanning to find classes in some corner cases (e.g. JAR files with missing entries). AFAIS JUnit Platform |
I have a test suite consisting of several JUnit tests and ArchUnit tests as my main artifact. To test these tests, I have several modules with different classpaths (mostly different versions of the same libraries) and check if the tests can be executed successfully with these classpaths. |
Context
I'm currently developing a library with common ArchUnit rules. To test them, I evaluate them against different classpaths. Therefor I created a multi-module Maven project:
The module
my-rules
contains my rules insrc/main/java
. The other modules have a dependency onmy-rules
and dependencies for test, but nosrc
folder.Description
In IntelliJ, when I select the module "tests-with-classpath1" and execute "Run 'All Tests'", the
ArchUnitTestEngine
tries to discover tests in the complete classpath, even in the JDK.It's because IntelliJ calls the registered TestEngines with
DiscoverySelectors.selectPackage("")
. However, if at least one class is present in the module, IntelliJ uses theClasspathRootSelector
. (The different selectors look inconsistent, which may be a cause of a bug/missing feature in IntelliJ: IDEA-354486)With the
PackageSelector [packageName = '']
, theArchUnitTestEngine
now scans the complete classpath including the JDK. On my machine, it takes about 30 seconds to discover all tests until the first gets executed.The behavior and implementation of
ArchUnitTestEngine
looks plausible, but I would be positively surprised about any@ArchTest
inside the JDK. I suggest to replace the implementation withorg.junit.platform.commons.support.ReflectionSupport#findAllClassesInPackage
which somehow does not scan the JDK.Reproducer
I created an example to reproduce the issue: https://github.com/rweisleder/demo-test-engine
The text was updated successfully, but these errors were encountered: