Replace jqwik.properties with JUnit Platform Mechanism for Configuration

[jlink]

Testing Problem

jqwik has its own way to configure itself: jqwik.properties. This has a couple of disadvantages:

• Users must be taught how to use it
• Users must create such a file in each of their projects
• There's currently no mechanism to override configuration parameters, e.g. through system properties or runtime parameters

Suggested Solution

Switch to the configuration mechanism built into the JUnit platform.

For versions 1.4.x the old mechanism must be kept for backwards compatibility.

The first implementation step should cover:

• Configuration properties can be loaded from jqwik.properties or from junit-platform.properties with an additional "jqwik." prefix
• Loading from jqwik.properties will log a WARNING
• Having a parameter in both file will log an ERROR. Parameter from junit-platform.properties has precedence
• Rename some of the config parameters for junit-platform.properties (log an ERROR if old name is used there)
  • defaultTries -> jqwik.tries.default
  • defaultMaxDiscardRatio -> jqwik.maxDiscardRatio.default
  • defaultGeneration -> jqwik.generation.default
  • defaultAfterFailure -> jqwik.afterFailure.default
  • defaultEdgeCases -> jqwik.edgeCases.default
  • defaultShrinking -> jqwik.shrinking.default
• Optional: Provide a tool to translate jqwik.properties into junit-platform.properties

Discussion

• Currently jqwik gets its configuration when creating the instance of JqwikTestEngine.
  The ConfigurationParameters instance is only available in discovery and execution requests.
  Maybe a first step should move the retrieval of JqwikConfiguration into the request methods to
  facilitate migration.

• JUnit's ConfigurationParameters interface does not provide a means to get all parameters with a certain prefix.
  That means that it will no longer be possible to warn about unused/unknown parameters (e.g. through spelling errors).

• Should camel case names be replaced by names with hyphens or underscores?

[osi]

On property naming, the JUnit Jupiter documentation does dot-separated lowercase. they use testinstance and autodetection instead of a camel-cased or adding other separators. a dot appears to be used for grouping (as it does with the proposed .default syntax).

[osi]

On the first discussion point, agreed. I was thinking of storing the configuration as a property on JqwikEngineDescriptor, as that descriptor will then be available during execution as the root descriptor.

[jlink]

On the first discussion point, agreed. I was thinking of storing the configuration as a property on JqwikEngineDescriptor, as that descriptor will then be available during execution as the root descriptor.

That doesn’t feel right to me because it requires a descriptor to be mutable. Descriptors were designed to be immutable; I think there are places where this is no longer the case but I wouldn’t do it if I can prevent it.

[jlink]

That doesn’t feel right to me because it requires a descriptor to be mutable. Descriptors were designed to be immutable; I think there are places where this is no longer the case but I wouldn’t do it if I can prevent it.

@osi Just had a look at the PR to realise that mutability is NOT required. Your approach looks unusual at first sight (because it stores additional info in the descriptor) but let’s see where it will lead you. It may also be worthwhile to look how Jupiter is doing it.

[osi]

Jupiter also stores the configuration as a property of the root descriptor.

https://github.com/junit-team/junit5/blob/main/junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/descriptor/JupiterEngineDescriptor.java#L33

[jlink]

The PR has been merged and released in "1.4.0-SNAPSHOT"

[jlink]

@osi There's one minor thing that I couldn't track down quickly: All logging done during configuration loading seems to appear twice when running tests, e.g.

INFORMATION: Loading JUnit Platform configuration parameters from classpath resource [file:/Users/link/Documents/git-projects/jqwik/documentation/out/test/resources/junit-platform.properties].

Is there a straightforward way to prevent duplicate logging? Maybe configuration loading must be lazy and cached?

[osi]

I'll take a look.

[jlink]

@osi The double logging comes from JUnit Platform itself, called by IntelliJ. One of the two is the culprit.
I guess we cannot do anything about it. So I close this issue as done.