Comments (12)
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.
Related Issues (20)
- StackOverflowError when shrinking large arrays HOT 14
- question: any way to imperatively summon a pre-configured arbitrary? HOT 15
- Make nested groups work for JDK >= 18 HOT 31
- Combinators.combine.as nullability of arguments HOT 4
- Can't figure out how to create an Arbitrary I want HOT 10
- Bug: Arbitraries.strings().uniqueChars() will sometimes shrink to values with duplicate chars HOT 5
- Bug: Uniform Distribution of Integers does not work if range is >= Integer.MAX_VALUE HOT 2
- Kotlin K2 Support HOT 24
- Time Module: Support generating java.sql.Timestamp
- adding `jqwik-kotlin` causes existing tests written in java to fail with NPE HOT 18
- Potential idea for running `SAMPLE_FIRST`/`SAMPLE_ONLY` for stateful tests HOT 2
- Lifecycle method called twice when subclassing HOT 4
- Cannot use Arbitrary.generator() outside jqwik HOT 6
- Is Arbitrary<@Nullable T> correct/intended under JSpecify semantics? HOT 32
- TypeUsage example from user guide fails in 1.8.x HOT 8
- Right Way to Integrate jqwik with DataFaker HOT 23
- Generic @Provide methods are sensitive to the type variables' names HOT 3
- Allowing Sampling of Arbitraries with Injected Seed HOT 4
- TestEngine with ID 'jqwik' failed to discover tests [BUG] HOT 4
- `@Spy` fields initalized by `closable = MockitoAnnotations.openMocks(this)` is not cleared by `closable.close()` for Jqwik HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jqwik.