Skip to content
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

Allow changing defaults for @Property #170

Open
csamak opened this issue Jul 25, 2017 · 3 comments
Open

Allow changing defaults for @Property #170

csamak opened this issue Jul 25, 2017 · 3 comments
Labels

Comments

@csamak
Copy link
Contributor

csamak commented Jul 25, 2017

There should be a way to change the default for @Property annotations so it doesn't always have to be done per-method. "Aggregating configuration" doesn't work in part because @Property can only be applied to methods, and I don't see another way to change the settings.

For example, for projects with complex types the default shrink depth may not be sufficient for most properties.

@csamak csamak changed the title Change defaults for @Property Allow changing defaults for @Property Jul 25, 2017
@pholser
Copy link
Owner

pholser commented Jul 26, 2017

@csamak Thanks for your interest in junit-quickcheck! Sounds like a great idea.

Any particular form you'd imagine the default to take? Attributes of a class-level annotation? Config file in well-known location/class path?

@csamak
Copy link
Contributor Author

csamak commented Jul 26, 2017

I think for consistency (so things "just work") the aggregating config method described here would be nice if possible.

On top of that, for my project I'd like something global (i.e. shrink timeouts will be the same for all classes). A new config file will work, but maybe there's an option that fits junit-quickcheck's existing model.

What do you think about a configuration provider users can register through the ServiceLoader, similar to generators? Or, is there any global setting precedent in JUnit?

@pholser
Copy link
Owner

pholser commented Oct 15, 2017

Maybe #173 can help. For method-level annotations like @Property, search for annotations on method, deep-annotation search on any such annotations, then jump up to enclosing class, then the superclass/superinterface hierarchy? Maybe such as Spring does?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants