-
Notifications
You must be signed in to change notification settings - Fork 51
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
Avoid execution of tests before generating the test image #76
Comments
That's correct: we do not need to execute the tests. But... collecting the list of UIDs is not the only goal of the
The Feature actually makes use of a "dry run" to register test classes for reflection: Lines 145 to 163 in b20363e
The same thing (i.e., "discovery" without "execution") can be done to find the UIDs of tests. But... we shouldn't do that blindly. Rather, if we go that route I think we should come up with a mechanism to copy the user's test configuration from the |
I've been doing research on getting more complex unit tests that use mocking libraries working with native-build-tools, and I think there might be one benefit to running the tests beforehand. I noticed libraries like Mockito or EasyMock use cglib for creating mock objects, and they will internally call ClassLoader.defineClass(..) to dynamically create mock classes for unit tests. This is referred to as "dynamic class loading" and is not supported in GraalVM by default:
However, there looks like some workaround solutions being attempted; the solution sounds like it extends the So if you run the tests beforehand in JVM mode, you can attach the native-image-agent to that run and record these dynamic class loads done by the mocking libraries using that feature. Then theoretically the work done in JVM mode can be carried over for the native-image run. There's probably other blockers but this might keep the door open to getting unit tests that use mocking libraries working. |
Is this ticket still relevant, @melix? |
Yes it is. |
Proposal
Currently, tests are executed in JVM mode, so that we can generate a list of test ids, which are in turn used as an input to generate the native test image. However, technically speaking, we don't need to run the tests: we only need to collect the test ids. So we could have some kind of "dry run" mode for tests which actually generate the test id list, but do not execute the tests in practice.
Note that this is orthogonal to this JUnit issue which basically integrates the feature of generating the test id list into JUnit: in addition, we also need a way to skip the execution altogether.
It is very well possible that such a mechanism already exists in JUnit, because for example Gradle's test distribution does something similar, with an initial discovery phase. @marcphilipp might have some insights.
The text was updated successfully, but these errors were encountered: