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

Add ability to limit tests by test duration rather than the number of test iterations #336

Closed
vlsi opened this issue May 19, 2022 · 8 comments

Comments

@vlsi
Copy link
Contributor

vlsi commented May 19, 2022

Testing Problem

I'm testing database-related integration cases like "create table", "drop table", and the sequence of operations is generated on the fly (see #134), so @Property(tries=42) is not suitable for me as I have no idea how much time a single iteration would take.

Suggested Solution

Support something like @Timeout from JUnit5: https://junit.org/junit5/docs/5.5.1/api/org/junit/jupiter/api/Timeout.html

The "test timeout" feature could be implemented via AfterProperty + AroundTryHook, however, having an out-of-the-box timeout would be perfect.

See https://www.fuzzingbook.org/html/WhenToStopFuzzing.html, https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/#duration-of-coverage-guided-fuzz-testing

@jlink
Copy link
Collaborator

jlink commented May 19, 2022

Should the time limit be in addition to number of tries or replace the number of tries?
What I mean @Property(tries = 10000, maxSeconds= 10) would stop depending on which occurs first: 10000 tries or 10 seconds.

@vlsi
Copy link
Contributor Author

vlsi commented May 19, 2022

@Property(tries = 10000, maxSeconds= 10)

That makes sense, and I have pretty much the same intention: allow stoping the test as soon as the first limit is exhausted.

As I started adding my own @Timeout I immediately realized I want to be able to pass the timeout from the command line to allow different CI jobs to have different fuzz durations.

I'm not sure what to do about it, and it might be that a generic "pass values from the command line" (e.g. via system properties) might be helpful.

For instance, what if jqwik picks up jqwilk.proprerty.com.acme.MyProperties.propertyName.tries=42 and uses that as an override for @Property on top of propertyName method in com.acme.MyProperties class?

@jlink
Copy link
Collaborator

jlink commented May 19, 2022

For instance, what if jqwik picks up jqwilk.proprerty.com.acme.MyProperties.propertyName.tries=42

This would make the most sense as a generic feature for all attributes accepted by @Property.

@vlsi
Copy link
Contributor Author

vlsi commented May 19, 2022

This would make the most sense as a generic feature for all attributes accepted by @Property

I moved the discussion to #337

In any case, I think it would be fine to put timeout to @Property(...) (and @PropertyDefaults).

@vlsi
Copy link
Contributor Author

vlsi commented May 19, 2022

Well, it is awesome there's net.jqwik.api.lifecycle.TryExecutionResult#satisfied(shouldPropertyFinishEarly=true) which would do exactly what I need for the timeout feature :)

@jlink
Copy link
Collaborator

jlink commented May 14, 2024

This will be supported by jqwik 2. So I close the feature request for jqwik 1.

@jlink jlink closed this as completed May 14, 2024
@vlsi
Copy link
Contributor Author

vlsi commented May 14, 2024

Is there an issue tracker for jqwik 2?

@jlink
Copy link
Collaborator

jlink commented May 14, 2024

Not yet, but there will be.

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

No branches or pull requests

2 participants