Testing Jakarta applications is harder than it should be. You wire together a JPA provider, a transaction manager, an embedded JAX-RS server, a test database, mock libraries and stub servers — and before you have written a single assertion, you have already written hundreds of lines of infrastructure. Then you do it again for the next project. And the next.
jawelte exists to end that. It is a Java test framework built on the Jakarta 10 platform that makes integration testing as simple as writing a plain JUnit test. One annotation. A running container. Your test.
The name is not an accident. Every letter earns its place.
jawelte has two logos. The version 1.0 logo is the target — the mark the project will carry once it reaches its first stable release. Until then, the work-in-progress logo is what you will see in repositories, docs and releases. Both tell the same story; the WIP logo carries a gear and checkmark to signal that we are still building — and that tests should pass.
The version 1.0 logo carries an x above the W — two-colored, the red \ a failing test, the green / a passing one. Together they form the universal symbol for a test result. The W below is built from two checkmarks mirrored on the y-axis — red left tick failing, green right tick passing.
The work-in-progress logo replaces the x with a gear and checkmark. The gear is a deliberate signal: jawelte is under active construction. Not ready. Not stable. Moving parts still turning. The checkmark inside it is the destination — tests that pass, reliably, every time. The word experimental below the tagline makes the status explicit: use it, try it, break it — but know what you are holding. When the gear disappears and the x returns, jawelte is done.
jawelte is not just built for Jakarta — it is built with it. CDI beans and events form its internal backbone. MicroProfile Config drives its configuration. Every abstraction jawelte exposes is backed by the same standards it helps you test.
Core technologies:
First-class integrations — all opt-in, all pluggable:
Every test method runs in its own CDI request scope. If you need a database, jawelte boots JPA and JTA, loads your test data, and wraps your entire test — setup, execution and assertion — in a single shared transaction. Before the assert phase, the EntityManager is flushed so you can inspect the real database state. Then the transaction is rolled back. No cleanup. No leftover state. Fast.
Test data is declared externally — via DB-Unit datasets — and referenced per test method through an annotation. Datasets can be shared across a test class or specific to a single method, or both combined. The framework loads them. You focus on the assertion.
jawelte is in active development. The core — JUnit 5 extension, CDI lifecycle, MicroProfile Config integration and the port/adapter SPI — is being built first. Integrations follow. Documentation and self-tests ship alongside the code, not after.
The goal is a framework the Jakarta community can rely on. Solid, fast, honest about what it does. And when your test passes — jawohl.