jqwik: property-based testing on the JUnit Platform

A test engine that plugs into JUnit 5

jqwik is an alternative test engine for the JUnit 5 platform that focuses on Property-Based Testing, and the link it points at is the JUnit documentation for custom engines and the launcher API.

That single architectural choice is the whole product. Rather than asking a project to adopt a new build, a new runner and a new reporting format, jqwik implements the JUnit Platform's engine contract. The result is that a project can mix ordinary JUnit 5 tests and property-based tests in the same module, and the same launcher, the same IDE integration and the same report carry both.

The repository topics say junit, junit5 and quickcheck, and that last one is the useful hint about where the ideas come from. Property-based testing in the QuickCheck tradition means you state a property, an invariant that should hold for a whole class of inputs, and the framework generates the inputs and shrinks the failing case. That is a different discipline from example-based testing, and it catches a different class of defect.

The primary language is Java, the licence is EPL-2.0, the default branch is main, the homepage is jqwik.net, and the last push was on 2026-10-13. The recent releases are 1.9.3 in June 2025, 1.10.1 on 2026-05-29 and 1.10.2 on 2026-10-10, and the javadocs badge points at the published API documentation, which is where you find the annotations that drive the generation.

The README is short by design, because everything else is on the website, and the project publishes a user guide there under a docs/current path.

Maintenance mode, stated in the first section of the README

The second section of the README is the one that tells you what this project is now, and it is unusually direct.

It says that jqwik is in pure maintenance mode, and that as long as no further sponsoring or other funding shows up, no further feature development will take place, unless the jqwik team has some personal interest in such a feature. What will happen, though, is a regular update of upstream dependencies, like the JUnit platform, and the fixing of the bugs the team considers essential. The triage of bugs into essential and non-essential is fully up to the jqwik team.

Every clause of that paragraph matters for an adopter. There is no feature roadmap, and the condition for one is funding rather than a maintainer's time. There is a steady stream of upstream updates, which is the part that keeps a test library usable, because a test engine that falls behind the platform it plugs into stops working. And the definition of which bugs get fixed is the team's, which is a perfectly normal arrangement but a real limit on what you can plan around.

The repository reflects that state. There is a BACKLOG.md and a TODO.md in the root, and there is a FEATURE_USAGE_SURVEY.md, which is a less common artefact and suggests the team is trying to work out what the users actually need from any future work.

The releases show that the project is not frozen, only quiet. Version 1.10.2 came out on 2026-10-10 with a title of Little Fix for IDEs, three days before the last push, so the maintenance commitment is being kept in practice as well as in the README.

The Anti-AI Usage Clause is the thing to read before you upgrade

The very first thing in the README, above the badges, is a notice at double the normal font size in italics, and it is about the terms rather than about the code.

It says to mind that starting with version 1.10 jqwik comes with an Anti-AI Usage Clause, and it links to the section of the user guide that explains it. The release history agrees: version 1.10.1, published on 2026-05-29, is titled Anti-AI Release, and the repository root contains a .noai file alongside the .editorconfig and .gitattributes.

The README does not spell out what the clause permits or forbids, and that is deliberate, because the clause text lives in the user guide, and the notice exists to stop you from upgrading without reading it. So the responsible thing is to read that section of the guide before you move a project onto 1.10 or later.

Why it matters in practice: jqwik is a test library, so its users are developers, and developers are exactly the people whose teams now generate code with assistants. A licence term that restricts that use is unusual enough to be worth reading carefully, and it lands on top of the EPL-2.0 licence rather than replacing it. The .noai file in the root is the machine-readable marker of the same intent.

The timing is worth noting as well. The clause arrived in the 1.10 line, in the same release cycle in which the project moved into maintenance mode, which is a period when a team is least likely to be adding features and most likely to be tightening the terms under which the existing ones are used.

A multi-module build, with the API separated from the engine

The top-level listing shows a project with a real module structure rather than a single source tree.

There is api/, base/, engine/, testing/, time/ and web/, which between them make up the library, plus kotlin/ and test-modular-api/ as separate lines of work, and experiments/ for whatever is being tried. There is documentation/ for the site content, buildSrc/ for Gradle build logic, and a dependencies.gradle that keeps the dependency versions in one place, alongside build.gradle, settings.gradle, gradle.properties and the gradlew wrappers.

The api/ module is the one that matters most to a consumer, because the javadocs badge points at net.jqwik:jqwik-api. Separating the published API from the implementation is what lets the engine and the platform adapters move without breaking your compile, and it is also what makes the compatibility story describable in terms of an artifact rather than a branch.

Two files in the root are unusual and both are about the publishing process. signalPublishToCentralSonatype.sh is the step that signals a release to the repository the artifacts are published to, which is the kind of operational detail that is usually buried in a wiki. jqwik-images.key sits next to it, which is the signing key reference for the published artifacts.

The .idea/ directory is present as well, so the project is developed in a JetBrains IDE and the configuration is shared, and the .github/ directory holds the CI workflow, whose badge is in the README.

What is still moving, and what has stopped

The maintenance mode statement is specific enough that it is worth spelling out what it means for each part of the project.

Upstream dependency updates continue, and the JUnit platform is named as the example. That is the highest-value maintenance a test engine can do, because the platform moves underneath it: an engine that is not rebuilt against a new platform release can stop discovering tests, and a project that upgrades its JUnit version quietly loses coverage.

The bug fixes that continue are the ones the team classifies as essential, and the README is explicit that the classification is theirs and not negotiable per issue. So a bug report is a request, not a commitment.

Features have stopped, with two exceptions: funding, and personal interest by the team. The second exception is worth naming because it is not a promise, and the first is the sort of arrangement where the people who benefit from a feature are the people who could fund it. If a feature matters to you, the project has told you what the route to it is.

What does not change is the shape of the library. A property-based testing engine on the JUnit Platform is a well-understood design, and the maintenance commitment is enough to keep a team running on it for a long time, provided they do not need the platform to move in a new direction.

For a team comparing this with writing property-based tests by hand, or with a separate property-testing framework that does not plug into JUnit, the difference is the integration point rather than the testing technique. jqwik keeps your existing launcher, your IDE and your reports, and the cost of that is that the engine is bound to the platform's own release cadence.

What to check before you adopt it

Three things, in order of importance for most teams.

First, the terms. Version 1.10 and later carry the Anti-AI Usage Clause on top of the EPL-2.0 licence, and the README's first line exists to make sure you notice. Read the user guide section it links to, and if your team writes tests with an assistant, that is the question to answer first. If the clause does not fit how you work, the 1.9.3 line is the last release before it, and that release is a normal upgrade path rather than a fork.

Second, the platform version. jqwik is a JUnit 5 engine, so the version of the platform you run decides whether the engine works at all. The maintenance commitment covers keeping the engine current with the platform, so check the current dependency floor in the build files, and read the release notes for the version you intend to pin.

Third, the API compatibility question. The version notes for the 1.10 line, and the API module split in the repository, are the places to look for what changed in the annotations and the engine contract. The published javadocs are the reference for what your test code should look like.

And a smaller, practical point: because the project explicitly asks for feedback on how it builds and works on your system, a project that adopts jqwik can feed problems back to the team. In maintenance mode, that channel is one of the few ways the work still moves, and it is worth a note in your issue template if you rely on the library.

Editorial conclusion

Adopt jqwik if you want property-based testing inside the JUnit 5 platform, so that your existing runner, IDE and build keep working while your tests generate inputs instead of listing them, because the engine plugs into the platform launcher API rather than asking you to change your build. Do not adopt it expecting new features, because the project states it is in pure maintenance mode with no further feature development unless funding appears or the team takes a personal interest. Before you use version 1.10 or later, read the Anti-AI Usage Clause, because it is a new term on top of the EPL-2.0 licence and it matters if your team generates code with an assistant, and check the current dependency floor because the platform updates that jqwik tracks are the only things still moving.

Frequently asked questions

Official sources

1. jqwik-team/jqwik on GitHub
2. License: EPL-2.0
3. Project website
4. README
5. Releases