jqwik-team / jqwik

Property-Based Testing on the JUnit Platform
http://jqwik.net
Eclipse Public License 2.0
568 stars 65 forks source link

Groovy Support #251

Open jlink opened 2 years ago

jlink commented 2 years ago

Testing Problem

jqwik has been built primarily for Java. Recently a kotlin module was added.

jqwik works in Groovy programms but their are a few places where using the Java API feels awkward and involved. Moreover, there are no built-in generators for types added by Groovy's SDK.

Suggested Solution

Add an optional groovy module to jqwik.

This will probably rely on Groovy 4, because some features, especially annotations for type variables do not work otherwise.

Features of Groovy Module

What else?

jlink commented 2 years ago

Please add suggestions about scope of Groovy module in comments.

akefirad commented 4 months ago

Provide arbitraries directly in @ForAll annotation, since Groovy allows code blocks in annotations. This will probably require a Groovy-specific annotation like @GForAll.

I would love to see this one. Maintaining method names is really cumbersome, and very much unnecessary in Groovy. I'll be more than happy to contribute if help is needed. PS: (I hope we don't have to call it GForAll tho) PPS: It's been a while since this issue is submitted. Can we start with something simple, not like an official extension. Later when we have enough confidence we can promote it to be an official extension. I'm happy to maintain it. Just need a little bit of help to get rolling.

jlink commented 4 months ago

Later this year - probably in late summer - development of Jqwik 2 is going to start. Groovy support could be a parallel effort if you want. We could use the time till then to discuss how good Groovy APIs should look like.

akefirad commented 4 months ago

Hm, ok. The thing is I don't consider myself a Groovy pro, so probably any API design by me would be sub-optimal. Also in our case, we don't use Groovy in production code (it's Kotlin) and also we put all of our test fixtures in a separate module (using Gradle Test Fixture plugin) which is again in Kotlin. So there's not so much need for us to design and develop a Groovy dedicated API. The most urgent need for us is making @ForAll compatible with Groovy closures.

Having said that, I'm more than happy to give a try. And I'd like to start by working on @ForAll and then iterating over the API.

As for the time line, I suspect the Groovy API would take some time to mature and be GA. So the question is how we should coordinate the timeline with the main project. My feeling is, for start it makes more sense to keep the two separate, specially because it'll take some time go from alpha to beta to GA which makes it hard to keep up with the main release timeline. WDYT?

jlink commented 4 months ago

The API won’t depend on the implementation details of jqwik 2, so I suggest you give it a try based on the current version.

As for aligning release timelines it’s much too early to consider that IMO. Moreover, Groovy support will come in its own module so there’s no need for synchronised release. Core and modules can move at different speeds.