-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate values outside of property parameters #211
Comments
It's an interesting problem which I have been considering in the context of jqwik.net. What we'd like to have is a combination of random generators and the test data builder pattern described in the GOOS book. Here's an old article by one of the GOOS authors: http://natpryce.com/articles/000714.html It looks rather simple at first glance since all we have todo is to replace the predefined default values in builder objects by calls to random generators. And indeed, it would be easy if we started with the builders and use random generators inside. However, starting with the already constructed random generator we'd have to deconstruct it to get into the nested parts which is not that easy. All I could think of so far - without deconstructing the generator - is something like that:
But this requires indeed some way to transform an already existing value. I'm hoping you folks'll come up with something better. |
@sir4ur0n Thanks for your interest! Perhaps we can come up with a way to present code other than property methods with the ability to generate random values. |
@sir4ur0n @jlink I'm struggling with how to tease the ability to generate a random value not under the influence of a For point 1) above: this may complicate individual generators a bit, but I wonder if adding config annotations to a generator to influence where specific composite values should be added would help? class Foo {
Foo withBar(Bar b) { /* ... */ }
Foo withBaz(Baz z) { /* ... */ }
// ...
}
class FooGen extends Generator<Foo> {
// ...
// where `@WithFixed` is a container annotation of `@With`,
// both of which you write
public void configure(@WithFixed fixed) {
// make a Foo, possibly with fixed attributes as dictated
}
}
// ...
@Property public void property(
@WithFixed(
@With(bar = "some-ref-that-can-be-resolved-to-the-bar-you-want")
@With(baz = "some-ref-that-can-be-resolved-to-the-bar-you-want")
) Foo f) {
// ...
} It moves the suck of building using the fixed values to the generators, with a cost of adding suck at the property declaration. Once junit-quickcheck supports meta-annotations, maybe the suck at the property site would be less. All of this seems very hoop-jumpy tho. |
I love this library & would also like to use the power of the generators in different contexts - particularly arbitrary objects/POJOs in tests that are not using property based testing. Taking on the current Counter example w/
I'd love to be able to write something like...
Where |
@kPOWz I wonder if https://glytching.github.io/junit-extensions/randomBeans might better suit your needs in this case? |
Hi,
I'm wondering if there's an easy way to invoke generators to build random values outside of property parameters.
I see 2 use cases:
Generator
orComponentizedGenerator
and so far, they seem to work great on properties.However sometimes, the generated values need a specific value in one or several of its fields, for a single property test. This seems overkill to create a new generator specifically for this issue.
Also, we never ever use mutability (no setters) so I can't use setters. We use immutable modifications (which create new instances) but this would force us to create a second variable with a new name.
I found an ugly way to do it by looking at your code and came with this:
Besides the fact that I could extract it in a generic method, there's the issue of edge cases: e.g. for a field of type
String
, the first random value is always the edge case""
(empty string), so this is not good enough.Another alternative is to write a whole new set of agnostic generators (e.g. based on random-beans) but it means we have to write all generators twice, which is a waste of time/energy.
What's your opinion/recommendation here please?
Thanks
The text was updated successfully, but these errors were encountered: