spock icon indicating copy to clipboard operation
spock copied to clipboard

Extract EmbeddedSpecRunner-related stuff to separate (publishable) module

Open szpak opened this issue 5 years ago • 4 comments

Issue description

Occasionally. it is confusing to have junit-platform-testkit provided as an optional spock-core dependency (with its own dependencies). Namely here and here.

Proposed solution

As regular tests with Spock don't need EmbeddedSpecRunner nor junit-platform-testkit it would be good to extract the related stuff (probably also with EmbeddedSpecification) to a separate publishable module (spock-testkit?) to make it used as a dependency for the Spock plugin writers or the people writing more sophisticated tests (which need to reproduce a complete (embedded) Spock life-cycle in Spock tests).

szpak avatar Jun 08 '20 10:06 szpak

I am hesitant to create a new module just to have a few classes in there. Would it suffice to update the Javadoc. It already states that its mostly for spock internally.

 * Utility class that allows to run (fragments of) specs programmatically.
 * Mainly intended for spec'ing Spock itself.

We could add a notice that its usage requires the junit-platform-testkit dependency. We already have several optional dependencies, e.g. byte-buddy, so the concept is not new.

leonard84 avatar Jun 09 '20 18:06 leonard84

The concept is not new, but for the other dependencies there is a clear and obvious error message. If the testkit is missing it is more a subtle crypted error message.

Vampire avatar Jun 09 '20 21:06 Vampire

In addition, byte-buddy or objenesis are used in regular testing (just with spying). However, EmbeddedSpecRunner is much more sophisticated tool for plugin writers or some dirty hacks. Having ~60 hits globally on GitHub for EmbeddedSpecRunner (let's skip related classes which also could be used) shows the scale. I can add a dependency manually (if needed) and I know what to expect (instead of a weird exception related to AssertJ).

szpak avatar Jun 09 '20 22:06 szpak

We could probably do something with Gradle's feature variants here, without introducing a new module.

leonard84 avatar Nov 04 '21 23:11 leonard84