Why the need for @ForAll about jqwik HOT 12 CLOSED

I don't think the intent is that much of a deal. When one wrote @Property I think it's quite explicit they're trying to write a property holding for all inputs, it's the default for property tests.
Since it's probably the 80% or the 95% of use cases, I'd rather make it implicit and by default, and instead have an annotation to disable automatic injection for the 5% or 20%. Ideally, a meta annotation so that it can be put on another annotation for special use cases (e.g. I'm creating a @AlwaysReuseTheSame annotation, that I can annotate with @DisableInjection provided by Jqwik, so that when a parameter has @AlwaysReuseTheSame annotation in a property, Jqwik backs off and lets any other extension mechanism take care of it (of course, throw as usual if no extension mechanism took care of it)).

Besides verbosity, I don't see any major disadvantage to keeping @ForAll explicit. But verbosity (or absence thereof) is a major feature in library choice. And everything that makes tests easier to read/write is IMHO a step in the right direction. And Java is already verbose enough 😄

from jqwik.

@jcornaz Thanks for chiming in!

Counting as +1 for making @forall optional. Currently not very high on jqwik's TODO list.

from jqwik.

When I started junit-quickcheck, the way you wrote property-based tests with it was to use the Theories runner and mark the randomized parameters with the annotation @ForAll. This was to leverage the ParameterSupplier capability of the Theories runner -- that is how the runner was told what values to invoke your PBT with. When junit-quickcheck began supplying its own runner (JUnitQuickcheck), the need for @ForAll sort of fell away -- the runner scraped @Property methods from the test class and ran those.

There's a certain appeal to @ForAll in how a PBT reads with it:

@Property void symmetric(@ForAll Thing a, @ForAll Thing b) {
    // ...
}

highlighting the intended universality of the test -- for any two Things you give me, such-and-such property holds.

Also, because @Forall's `value attribute allows reference to provider methods, the readability aspect becomes even stronger:

@Property void symmetric(@ForAll("speciallyCrafted") Thing a, @ForAll Thing b) {
    // ...
}

All that said, I'd be OK with making @ForAll optional, and if the need arises to suppress parameter injection address it another way.

from jqwik.

It's not a technical limitation. In the current state of the system it would probably only be a few lines of code to make @ForAll optional. Two points made me decide to require it:

• IMO it makes the intent of properties as such more explicit. I was considering @ForAll, @ForAny and @Any at the time and chose @ForAll for pure gut feeling.
• Not requiring any annotation would make backwards compatibility harder as soon as parameter injection - similar to JUnit 5's Jupiter engine - will be possible.

Except for verbosity do you see any other disadvantage in annotating parameters with @ForAll?

from jqwik.

The case for making @ForAll optional does not look very strong in my opinion. Going bach from optional to required, however, will be a breaking change.

I'll leave this issue open for the time being and wait for more feedback and opinions.

from jqwik.

I agree with @sir4ur0n.

As soon as one writes @Property the intent is clearly to write a property holding for all input. The @ForAll is only boilerplate. And I think avoiding the need for boilerplate is always good.

from jqwik.

I actually like the @ForAll, as it makes reading more fluent......... except for maybe @Every would be even better, as the property only tests one instance at a time ;-) i.e.:
@Property should_be_divisible_by_two(@Every @Even @Positive Integer i)

from jqwik.

If you prefer @every over @forall you can define that annotation and use it. The mechanics to do that are described here: https://jqwik.net/docs/current/user-guide.html#self-made-annotations

from jqwik.

I tried

@Target({ANNOTATION_TYPE, PARAMETER})
@Retention(RUNTIME)
@Documented
@ForAll
public @interface Every {
    String NO_VALUE = "";

    String value() default NO_VALUE;
}

but I get a JqwikException: All parameters must have @ForAll annotation.

from jqwik.

Looks like a bug at first glance. I'll have a look at it.

from jqwik.

@t1 It was a bug indeed. Using 1.2.1-SNAPSHOT from https://oss.sonatype.org/content/repositories/snapshots will now allow you to user @Every instead of @ForAll. What does not work are annotation parameters, though. Thus, @Every("strangeThing") will NOT use the generator from method strangeThing. If you need that please open a new issue in order to discuss it.

from jqwik.

Since lifecycle hooks (#61) are eventually coming to jqwik I'm working on parameter injection. @ForAll will now be necessary to differentiate between injectable and non injectable parameters.

Therefore I've decided to keep @ForAll mandatory for parameters that are supposed to be randomly generated.

from jqwik.