Support specifying when @BeforePropety is invoked in relation to hooks

[adam-waldenberg]

Testing Problem

There doesn't seem to be a way to control if @BeforeProperty methods should be invoked before or after hooks. At first, I thought the proximity influenced this, but this does not seem to affect anything else than how hooks are executed in relation to each other.

Suggested Solution

Maybe add a @BeforePropertty(beforeHooks=true/false). Alternatively add a "proximity" to when methods with these annotations are executed and then allow the hooks to work around them by setting proximity().

[jlink]

Well, in theory (I just checked the code), the proximity of any AroundPropertyHook should influence the behaviour.
Methods annotated with @BeforeProperty run with a proximity of -10. So if your hook should run after @BeforeProperty methods the proximity should be > -10, and respectively < -10 to run before.

I extended the tests to make that clear: https://github.com/jlink/jqwik/blob/main/engine/src/test/java/net/jqwik/engine/execution/lifecycle/LifecycleMethodsTests.java
So I'd say that the documentation of aroundPropertyProximity() is correct.

That said, it could be a new feature to influence the proximity of individual before/after methods through an attribute in @BeforeProperty and @AfterProperty. This would require a larger change in the implementation, though.

[jlink]

I assume I could answer your question. If not, please re-open the issue.

[adam-waldenberg]

Aha. Thanks @jlink. I completely missed this. It will do for now!

However, I agree that it would probably be useful to be able to influence this on a per-test basis.

[jlink]

Would ˋAddLifecycleHook(value=HookClass.class, proximity = 100)ˋ do?

[adam-waldenberg]

Yeah... That would work. I think it would also make it clearer in showing in what order things fire if it had the default for that property set as referenced in the documentation in your previous comment.

One case to consider would be if the hook is defined on the class rather than per-method and how one overrides the other. I guess whenever that fine grained control is needed, it's not the end of the world to have to define it for each method though.

[jlink]

@adam-waldenberg As described in #398 it's not as simple as I originally thought it could be.