What the agent does
The agent reads the Gradle build and package layout first. In gothinkster/spring-boot-realworld-example-app it finds build.gradle on Spring Boot 2.6.3, Java 11, MyBatis, Netflix DGS GraphQL 4.9.21, Flyway, JJWT, SQLite, Spotless with Google Java Format, and tasks.named('test') { useJUnitPlatform() }. Production code under src/main/java/io/spring splits into api (MVC controllers, JWT filter, security config), core (entities and AuthorizationService), application (query services), infrastructure (MyBatis repositories and JWT service), and graphql (data fetchers and mutations). Tests under src/test/java already cover many API and MyBatis paths (ArticlesApiTest, UsersApiTest, MyBatisUserRepositoryTest, ArticleTest for slug behaviour) but leave gaps in places such as AuthorizationService, Util, GraphQL fetchers (ArticleDatafetcher, CommentMutation, SecurityUtil), and some infrastructure helpers.
It runs ./gradlew test with JaCoCo (adding the JaCoCo plugin to build.gradle only when the project has no coverage task yet) and ranks main sources by missed lines. The five files it picks must hold branches: for example AuthorizationService.canWriteArticle / canWriteComment, GraphQL security helpers, exception handlers under api/exception, or query services without a matching *Test.java. Envelope DTOs and generated DGS classes are skipped.
New tests are JUnit 5 (org.junit.jupiter.api.Test) in the matching package under src/test/java, following styles already in the repo: Hamcrest assertions like ArticleTest, Spring @SpringBootTest / MockMvc / RestAssured where neighbouring API tests use them, and plain unit tests for pure core services with constructed User, Article and Comment instances. Behaviour is the focus: authorization true/false matrix, slug edge cases not already listed, GraphQL error paths when the current user is missing.
It re-runs the Gradle test task with coverage, puts before/after figures in the pull request description, and leaves production Java unchanged unless a test finds a bug (documented in the description). Spotless formatting is applied so the PR does not fail the format check. The clean task's deletion of ./dev.db is respected so leftover SQLite files from one attempt do not poison the next.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Run the test suite with coverage, pick the five least-covered files that hold real logic, and write JUnit 5 tests for them that exercise behaviour, not implementation details. Do not change production code unless a test reveals a bug; if it does, say so in the description. Open a pull request with the coverage before and after.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- 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 on a new branch. In a RealWorld Spring Boot repo it adds JUnit 5 classes under src/test/java/io/spring/..., may add a JaCoCo block to build.gradle when coverage was missing, and keeps src/main/java clean absent a named bug fix.
The description lists the five files, coverage before and after, and the Gradle commands used. The trajectory keeps ./gradlew test output and any SQLite dev.db cleanup from the clean task, so a reviewer can see flaky file locking if it happened.
Before merging, a reviewer checks Java 11 compatibility, that GraphQL tests do not require an external network, and that Spotless still passes. Once merged, the Java CI workflow runs the new tests with the same JUnit Platform settings already in build.gradle.
Run it on every domain service or GraphQL fetcher added
On pull requests that add files under io.spring.core or io.spring.graphql without a matching test, send this request so JUnit coverage arrives before merge.
Wire the API key webhook for run.completed / run.failed and keep Gradle runs inside max_concurrent so the sandbox is not flooded with JVM builds.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
Spring Boot tests need the right JDK, Gradle wrapper, and often an in-memory or SQLite database. Running that loop on a laptop while juggling other services is slow. On Rush the agent uses the project's gradlew, writes JUnit 5 tests in the repo's style, and opens a pull request that already passes.
Coverage numbers on the pull request and the Gradle log in the trajectory are the proof. The same request can raise coverage on several Spring services in parallel, each reviewed separately.
Frequently asked questions
JUnit 4 or JUnit 5?
JUnit 5. The build already calls useJUnitPlatform() and existing tests import org.junit.jupiter.api.Test.
Will it upgrade Spring Boot 2.6?
No. This job only adds tests (and JaCoCo if needed). Framework upgrades are a different request.
Are GraphQL tests included?
Yes when coverage points at io.spring.graphql. The agent follows DGS testing patterns already possible with spring-boot-starter-test rather than adding a second framework.
MyBatis tests against which database?
Whatever the test resources already use (SQLite in this RealWorld app). The agent does not point tests at a shared staging database, and it does not commit a leftover dev.db from the sandbox into the pull request.