# Write Tests for a Quarkus Service

Yes. An agent writes @QuarkusTest and REST Assured tests for your endpoints' error paths, runs ./mvnw verify against Dev Services, and opens a pull request.

[Run this on Rush](https://cloud.getrush.ai/run/write-quarkus-tests/quarkus/), in a Project that has your repository.

## 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`

```json
{
  "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"
    }
  ]
}
```

1. **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.
2. **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.
3. **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.

## 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.