Add support for test engine jqwik#3298
Closed
gtrefs wants to merge 45 commits intotestcontainers:masterfrom
Closed
Add support for test engine jqwik#3298gtrefs wants to merge 45 commits intotestcontainers:masterfrom
gtrefs wants to merge 45 commits intotestcontainers:masterfrom
Conversation
The TestContainersExtension of Jupiter was adapted to support the BeforeContainer, AfterContainer and AroundProperty hooks. They work in the same way as the Jupiter pendants. However, the Container annotation was renamed to TestContainer because the name container is already used in Jqwik for any class which contains properties. Further, the store in Jqwik is not bound to its current context and not a key-value store. Though, it can be scoped to the overall run, property or the current try.
Converted parameterized test into a property.
Converted test from Jupiter to Jqwik
A PropertyLifecyclyeContext does not provide the means to access the parent instance. This makes it hard to access the parent test instance. The nested container is started and stopped. Different to Jupiter, Jqwik traverses the tree of test elements bottom-up and first runs the properties within a group.
Shared containers are available in a group.
Containers in groups are started and stopped.
If a container is lifecycle aware, it is handed over the exception, if there was one after property execution.
In order to better align with the Jupiter extensions, the TestContainer annotation was renamed again to Container.
Stores in Jqwik don't close entries of any kind. Similar functionality is achieved by using the onClose callback.
The runtime databse stores data of the previous engine run. Thus, the file should not be stored in git.
Started documentation of the jqwik lifecycle hook.
Updated documentation.
Author
|
I talked to Johannes. I am going to add the |
A Container annotation now supports a flag called restartPerTry which causes containers to be started before each try and stopped after a try. LifeCycleAware containers are not yet supported.
Author
|
I added support for restart after each try |
Author
Member
|
Sorry for not commenting sooner - as you can see we're quite underwater with the number of PRs at the moment, and we're focused on the urgent issue of Docker Hub rate limiting coming up. We saw jqwik-team/jqwik-testcontainers#1 and we think that's a good approach for everybody. Kotest did similarly. |
Author
|
@rnorth I pushed the code to https://github.com/jlink/jqwik-testcontainers |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request adds support for the property-based testing engine jqwik. jqwik is a junit platform test engine. Lifecycle Hooks in Jqwik are still experimental. I will ask Johannes Link to have a look at this PR. Maybe he has some additions.
The module should use as few dependencies as possible,
Regarding libraries, either:
compileOnlyif they are likely to already be on the classpath for users' tests (e.g. client libraries or drivers)implementation(and thus transitive dependencies) if they are very unlikely to conflict with users' dependencies.If client libraries are used to test or use the module, these MUST be legal for Testcontainers developers and Testcontainers users to download and use.
Every module MUST have a dedicated documentation page containing:
Consider that many users will not read the documentation pages - even if the first person to add it to a project does, people reading/updating the code in the future may not. Try and avoid the need for critical knowledge that is only present in documentation.