What the agent does
The agent reads the service and the tests it already has. In quarkus-quickstarts' hibernate-orm-panache-quickstart, pom.xml sets quarkus.platform.version 3.40.1 and maven.compiler.release 17, with quarkus-hibernate-orm-panache, quarkus-rest-jackson, quarkus-jdbc-postgresql, quarkus-junit and rest-assured. application.properties gives a PostgreSQL URL only under the %prod profile, so in tests Quarkus Dev Services starts a PostgreSQL container on its own, and import.sql loads Cherry, Apple and Banana into both tables. The one existing test, FruitsEndpointTest, lists fruits, deletes id 1 and lists again, for both /entity/fruits and /repository/fruits; nothing tests a failure.
It maps every error path in the two resources, FruitEntityResource and FruitRepositoryResource. GET, PUT and DELETE on an id that does not exist throw WebApplicationException with 404. POST with an id already set throws 422, and PUT with no name throws 422. Each resource's ErrorMapper turns every exception into JSON with exceptionType, code and error, so the tests assert the body shape as well as the status.
Then it writes FruitsErrorPathsTest as a @QuarkusTest with REST Assured, one parameterized case per endpoint and path prefix so both styles are covered. It does not assume Cherry is still there, because the existing test deletes id 1 against the same Dev Services database and test order is not fixed; each test creates the fruit it needs and uses ids far above the ALTER SEQUENCE ... RESTART WITH 4 range for the not-found cases. It runs ./mvnw verify, which runs every @QuarkusTest through Surefire; the existing FruitsEndpointIT only runs under the native profile, where Failsafe is configured, so the plain build leaves it out.
Some error paths the code does not handle, and the tests show it. FruitEntity.name is @Column(length = 40, unique = true), but nothing checks it before persist(), so a duplicate name or a 41 character name fails in the database and the ErrorMapper answers 500 instead of 409 or 422. POST with no name at all is accepted and creates a nameless fruit. The agent writes those as tests of the intended status, disables them with a reason, and lists them in the pull request.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "In hibernate-orm-panache-quickstart, write @QuarkusTest tests with REST Assured for every endpoint's error paths, using Dev Services for the database. Run ./mvnw verify and open a pull request.",
"resources": [
{
"url": "https://github.com/your-org/your-quarkus-service"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
What comes back is a pull request that adds src/test/java/org/acme/hibernate/orm/panache/FruitsErrorPathsTest.java and, if needed for parameterized cases, junit-jupiter-params in pom.xml. It covers 404 for unknown ids on get, update and delete, 422 for a preset id on create and a missing name on update, and the ErrorMapper JSON body, for both the entity and repository resources. The resources and import.sql are unchanged.
The description lists each case with its expected status, and every disabled test with the behavior it found: a duplicate or overlong name answering 500, and a create with no name succeeding. The session's trajectory keeps the full ./mvnw verify output, including Dev Services starting PostgreSQL and the Surefire report.
Before merging, a reviewer checks that the tests do not depend on run order, decides which disabled cases are bugs to fix (validation with @NotBlank and @Size, or mapping the constraint violation to 409), and confirms CI can start containers for Dev Services. Fixing the service is a follow-up on the same session.
Run it on every new REST endpoint
When a pull request adds a JAX-RS resource or a new @Path method, a GitHub webhook can send this request with that pull request in resources, asking for error-path tests for the new endpoints only. The agent works on that branch in its own sandbox and runs ./mvnw verify there.
Set a webhook URL on the API key and Rush POSTs run.completed or run.failed when the turn finishes, so your server can link the test branch on the pull request. A key runs at most max_concurrent sessions at once, 4 by default, and answers 429 past that.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
A Quarkus test run starts the application, and with Dev Services it also starts a database container, which on a laptop means Docker running, a full Maven build, and a terminal you are not using for anything else. In its own sandbox the agent runs ./mvnw verify as many times as it needs while writing the tests, and your machine is not involved.
The pull request carries the proof: the trajectory has every Maven run with its output, so a reviewer can see Dev Services start, each test pass, and why each disabled test is disabled. Because runs are isolated, the same request can add error-path tests to many services at once, each with its own database.
Frequently asked questions
Does Dev Services work in the sandbox?
Dev Services needs a container runtime to start PostgreSQL. When the sandbox can start one, the tests run against a real database exactly as they would in CI. When it cannot, Quarkus fails at startup with a clear message, and the agent reports that instead of switching to an in-memory database that behaves differently.
Will the new tests break the existing FruitsEndpointTest?
They are written not to. The existing test deletes Cherry from the shared Dev Services database, so the new tests create their own rows and never assume the seed data is intact. The trajectory shows the whole suite passing together under ./mvnw verify.
Why are some tests disabled?
Because the service does not do what the endpoint implies: a duplicate name answers 500, and a fruit with no name is accepted. A disabled test with a reason records that without making the build red, and the pull request lists each one so you can choose to fix it.
Does it work with Gradle?
Yes. With gradlew in the repository, the agent runs ./gradlew test instead, and the @QuarkusTest and REST Assured code is the same. Name Gradle in the prompt if both build files exist.