Data Driven Specs

It is an often requested feature and with the new flexibility that the JUnit Platform gives us, we can finally implement it in a nice way. (This issue supersedes #668).

Goals

• Offer a way to execute a whole Specification for a set of parameters, similar to data-driven features.
• A data-driven Specification should behave like a normal one, with the addition that there are injected parameters.
• This feature should integrate well with the existing functionality in terms of UX/DX. It should feel natural.

Open Questions

1. How do we deal with inheritance?
   1. Forbid Inheritance
   2. Create the Cartesian product of the parameters
   3. Treat them as extensions, requiring same size and just join both parameters
2. How do we define the data-variables?
   1. with a special static where method
   2. with a static inner class that is either annotated or implements a certain marker interface and has a where method or something similar
3. How do we inject the data-variables?
   1. automatically define them as properties with the same name
   2. require the user to define the properties in the spec, allowing typing
   3. a combination of the above
   4. if we use a the inner class approach (2.ii) we can just inject a instance of that class and have the properties be members of that class, either explicit or implicit. This would have the added benefit of isolating them visually in the code.
4. How do we deal with spring or similar extensions
   1. the spring extension can currently only inject in non-shared fields (there are a workarounds for that https://github.com/spockframework/spock/issues/76#issuecomment-241698357). However, those will probably not work for the spec level.
5. How do we deal with @Shared and setupSpec/cleanupSpec for Spec iterations
   1. Add some kind of @SharedForIteration and setupSpecIteration/cleanupSpecIteration
   2. don't support iteration specific sharing
   3. something else
6. How to report during discovery (currently, data-driven features are reported purely dynamic, if we did the same the specs then they wouldn't report any features during discovery)
   1. Don't report any features during discovery
   2. Distinguish between data-driven and non-data-driven specs and report feature for the latter
   3. Somehow detect self contained data providers (i.e., ones without field or function access) and run them during discovery, (this could be ported to features as well)
   4. something else

Please comment: @spockframework/supporter

Start by reviewing the existing data-driven feature behavior and the JUnit Platform integration mentioned in the issue. Work through the open questions on inheritance, data definition and injection, extensions, lifecycle methods, and discovery reporting. Done means a decided design and an implementation that makes data-driven Specifications behave like normal ones with injected parameters.