spockframework
Compatibility with GraalVM junit-platform-native
Is your feature request related to a problem?
I've been trying to run Spock tests on native code using the native-maven-plugin. It requires adding a huge list of classes to be initialised at build time (I suspect it may include most of the spock-core classes), and even then, the tests still don't run.
Detailed information about the tests I've done: The Specification is minimal—just one test method that calls the method under test and checks that it returns a non-empty collection. The test runs correctly over Java bytecode using the maven-surefire-plugin. I'm using:
- Windows 11 x86_64
- Visual Studio Build Tools 2022 17.12.4, Windows 11 SDK (10.0.22621.0 and 10.0.26100.0), Windows 10 SDK (10.0.20348.0), MSVC v143.
- GraalVM CE 24.0.1 Win64
- Git bash for Windows 2.49.0
- Maven, both 4.0.0-rc-2 and 4.0.0-rc-3
- gmavenplus-plugin 4.2.0
- native-maven-plugin 0.10.6
- spock-core both 2.3-groovy-4.0 and 2.4-M6-groovy-4.0
- groovy 4.0.26
- JUnit 5.10.0 (to align it with the version used by junit-platform-native 0.10.6). Also tried with 5.12.2.
- The problem also reproduces under Linux.
Error when running the tests: spockNative.txt
List of classes for build-time initialisation: --initialize-at-build-time=org.spockframework.runtime.SpockEngineDescriptor,org.spockframework.runtime.SpockEngine,org.spockframework.runtime.SpecNode,org.spockframework.runtime.RunContext,org.spockframework.runtime.GlobalExtensionRegistry,org.spockframework.runtime.extension.builtin.UnrollConfiguration,org.spockframework.report.log.ReportLogConfiguration,spock.config.RunnerConfiguration,org.spockframework.tempdir.TempDirConfiguration,org.spockframework.runtime.SimpleFeatureNode,org.spockframework.runtime.model.FeatureInfo,org.spockframework.runtime.model.SpecInfo,org.spockframework.runtime.extension.builtin.UnrollExtension,org.spockframework.runtime.extension.builtin.OptimizeRunOrderExtension,org.spockframework.runtime.extension.builtin.IncludeExcludeExtension,spock.config.ParallelConfiguration,org.spockframework.runtime.DefaultParallelExecutionConfiguration,org.spockframework.runtime.IterationNode,org.spockframework.runtime.model.IterationInfo,org.spockframework.runtime.model.MethodInfo,org.spockframework.runtime.condition.ObjectRendererService,org.spockframework.runtime.model.parallel.ExecutionMode,org.spockframework.runtime.condition.DiffedArrayRenderer,org.spockframework.runtime.condition.DiffedSetRenderer,org.spockframework.runtime.model.MethodKind,org.spockframework.runtime.model.Invoker,org.spockframework.runtime.condition.DiffedObjectAsBeanRenderer,org.spockframework.runtime.condition.DiffedObjectAsStringRenderer,org.spockframework.runtime.condition.DiffedCollectionRenderer,org.spockframework.runtime.condition.DiffedMapRenderer,org.spockframework.runtime.condition.DiffedClassRenderer,org.spockframework.runtime.RunContext$1,org.spockframework.runtime.extension.builtin.GlobalTimeoutExtension,org.spockframework.runtime.extension.builtin.TimeoutConfiguration,org.spockframework.runtime.extension.builtin.ThreadDumpUtilityType$2,com.oracle.graal.pointsto.constraints.UnsupportedFeatureException,org.spockframework.runtime.extension.builtin.ThreadDumpUtilityType$1,org.spockframework.mock.runtime.MockMakerConfiguration,org.spockframework.runtime.extension.builtin.SnapshotConfig,org.spockframework.runtime.model.BlockInfo,org.spockframework.runtime.model.BlockKind
Describe the solution you'd like
Spock is by far the best testing framework I've ever tried, and I want to continue using it; however, I also need to test native executables. It would be a very welcome feature for me, and for anyone working with GRAALVM and Spock, if it were compatible with native testing. It primarily boils down to ensuring that you don't initialise something at build time that should be initialised at runtime, although I'm not sure how much work that entails.
Describe alternatives you've considered
No response
Additional context
No response
Why do you think this is a Spock problem? In the file you attached, the exception that is coming is from static initializer of a Groovy class, so I'd guess this is a Groovy problem, not a Spock problem?
If what you ask for (or also ask for) is to remove the need to add all these classes to --initialize-at-build-time, then you might need to be much more verbose. I don't know about the others, but I have no experience with GraalVM at all and have no idea when or why you need to add something there or how to prevent it.
You probably also need to provide some MCVE so that it can easily be reproduced without trying to reproduce your setup from your description, especially when not having experience with GraalVM. This could for example also be a pull-request to the https://github.com/spockframework/spock-example project which could then also serve as example how to use GraalVM if it was made working.
As you seem to be familiar with GraalVM and Spock, optimally you would work on a PR to fix this, which would be very welcome. :-)
