How does Atlas run only one specific Quarkus test?

Atlas uses its `bash` tool to execute `Maven` with the `-Dtest` flag, targeting a specific `JUnit 5 (@QuarkusTest)` class or method. For example, it might run `./mvnw test -Dtest=com.example.MyServiceTest#myMethod` to isolate the failing test.

Can Atlas debug issues related to Quarkus build-time augmentation?

Yes, Atlas understands the context of Quarkus's build-time augmentation. While debugging, it focuses on fixing the underlying Java code that influences the augmented output, rather than the generated code itself, ensuring compatibility with native-image constraints.

How does Atlas navigate complex Quarkus dependency graphs?

Atlas leverages its `lsp` tool, which understands Java's type system and `CDI` annotations like `@Inject`. It can perform `goToDefinition` and `findReferences` to trace dependencies between `CDI beans` and `JAX-RS resources` within your Quarkus project.

What if my Quarkus test requires specific `application.properties` settings for debugging?

Atlas's `bash` tool can re-run `Maven` tests with additional system properties or modify `application.properties` using `edit` to temporarily adjust logging levels (e.g., `-Dquarkus.log.level=DEBUG`) or other configurations relevant to the test.

How does Atlas ensure code quality after a fix in Quarkus?

After applying a fix, Atlas ensures code quality by invoking `Spotless` via `Maven` (`./mvnw spotless:apply`) before committing. This automatically formats the modified Java files according to your project's defined standards, maintaining consistency.

Does Atlas support `RestAssured` tests in Quarkus?

Yes, Atlas can read and understand `RestAssured` tests written for `JUnit 5 (@QuarkusTest)`. It can trace calls from `RestAssured` assertions back to the `JAX-RS resources` they exercise, using `lsp` to work through the relevant code paths.

How does Atlas handle reviewing proposed changes in a Quarkus project?

Atlas provides a unified diff for every proposed file edit, which you must approve before it writes to disk. All tool calls are permission-gated, and Atlas drafts a plan in a read-only agent for your review before executing any changes to your Quarkus codebase.

Debug a Single Failing Test in Quarkus with Atlas in 2026

To debug a single failing test in Quarkus with Atlas, you will run the specific test using `Maven` and `JUnit 5 (@QuarkusTest)` via Atlas's `bash` tool, then use `lsp` to work through the call graph, and finally `edit` or `apply_patch` to fix the underlying production code, ensuring `Spotless` formatting is applied before committing.

How Atlas Isolates and Runs a Single Quarkus Test

Atlas isolates and runs a single failing Quarkus test using its `bash` tool, leveraging `Maven`'s `-Dtest` flag to target specific `JUnit 5 (@QuarkusTest)` methods. This approach ensures that only the relevant test executes, providing a focused output for analysis, often reducing execution time to under 10 seconds.

When a specific `@QuarkusTest` case fails, Atlas can execute just that test method or class. Instead of running the entire `Maven` test suite with `./mvnw test`, Atlas uses its `bash` tool to invoke `Maven` with a precise filter. For example, to run a single test method `myFailingMethod` within `com.example.MyServiceTest`, Atlas would execute a command similar to `./mvnw test -Dtest=com.example.MyServiceTest#myFailingMethod`. This direct execution within a real shell environment means all standard `Maven` and `JUnit 5` debugging levers, such as verbose logging or specific system properties, are fully available to Atlas, just as they would be if you ran them manually. This isolation is crucial for quickly reproducing and understanding the failure without the noise of other passing tests.

Navigating Quarkus Code with Atlas's LSP Tool

After identifying a failing `JUnit 5 (@QuarkusTest)` assertion, Atlas uses its `lsp` tool to work through the Quarkus codebase, tracing the call graph from the test to the production code. This allows Atlas to understand the flow through `CDI beans` and `JAX-RS resources`, often revealing the root cause within 2-3 navigation steps.

Once a test failure is observed, Atlas employs its `lsp` (Language Server Protocol) tool to perform `goToDefinition` and `findReferences` operations. This is particularly effective in Quarkus, where `CDI` (Contexts and Dependency Injection) is heavily used. Atlas can follow `@Inject` annotations to understand dependencies, or trace `JAX-RS` `@Path` annotations from a `RestAssured` call in a test to the actual resource method. For instance, if a test in `src/test/java/com/example/MyResourceTest.java` fails while calling `/api/myresource`, Atlas can use `lsp` to jump directly to the `MyResource` class in `src/main/java/com/example/MyResource.java` and then explore its injected services. This deep understanding of the code's structure, powered by `tree-sitter` for AST indexing, allows Atlas to form accurate hypotheses about the bug's location.

Forming and Testing Hypotheses in Quarkus

Atlas forms hypotheses about the failing Quarkus code and tests them by adding temporary logging or re-running tests with verbose flags. This iterative process, often involving 1-2 rounds of modification and re-execution, helps pinpoint the exact line causing the `JUnit 5` test to fail.

With a call graph mapped, Atlas drafts a plan to test its hypothesis. This often involves using the `edit` tool to insert temporary logging statements into the production code, such as `System.out.println()` or `Logger.debug()` calls, within relevant `CDI beans` or `JAX-RS resources`. Alternatively, Atlas can re-run the single failing test via `bash` with additional `Maven` flags, like `-Dquarkus.log.level=DEBUG` in `application.properties`, to increase the verbosity of Quarkus's internal logging. After each modification or flag change, Atlas re-executes the specific `JUnit 5 (@QuarkusTest)` to observe the new output. This focused feedback loop allows Atlas to quickly confirm or refute its assumptions about the bug's location and behavior, leading to an efficient diagnosis.

Fixing Quarkus Code and Ensuring Quality with Spotless

Atlas fixes the identified issue in the Quarkus production code using its `edit` or `apply_patch` tools, then re-runs the `JUnit 5` test suite to confirm the fix. Before committing, Atlas ensures code quality by applying `Spotless` formatting, a critical step in maintaining a consistent codebase in 2026.

Once the root cause is identified, Atlas proceeds to fix the production code. For small, localized changes, the `edit` tool is used to modify specific lines. If the fix spans multiple hunks or requires more complex structural changes, Atlas can generate and apply a unified diff using `apply_patch`, ensuring atomic and reliable modifications. After the fix, Atlas first re-runs the single failing `JUnit 5 (@QuarkusTest)` to confirm the specific issue is resolved. Then, it executes the full `Maven` test suite (`./mvnw test`) to ensure no regressions were introduced. Finally, before staging and committing the changes, Atlas invokes `Spotless` via `Maven` (`./mvnw spotless:apply`) to automatically format the modified files, adhering to the project's coding standards and ensuring a clean, consistent codebase.

Atlas's Safety and Review Mechanisms for Quarkus Changes

Atlas incorporates robust safety and review mechanisms, including permission-gated tool calls and unified diffs, ensuring every change to your Quarkus project is transparent and approved. This process provides 100% control over modifications, from `pom.xml` updates to `CDI bean` adjustments.

Every action Atlas takes, from running `bash` commands to editing files, is permission-gated. Before any tool call, Atlas checks against allow, ask, or deny rules, giving you explicit control. When Atlas proposes a code fix, it first drafts a plan in a read-only agent, which you review. Only after approval does it switch to a build agent to execute the plan. For every file modification, Atlas computes a unified diff and presents it for your approval before writing to disk. This applies to all Quarkus-specific files, whether it's a change in `src/main/java`, `application.properties`, or even the `pom.xml`. Atlas also snapshots file changes as git patches, allowing for easy diffing and rollback, providing a secure and auditable workflow for debugging and fixing issues in your Quarkus applications.

Step by step

01Atlas runs the single failing `JUnit 5 (@QuarkusTest)` in isolation using its `bash` tool, executing a `Maven` command like `./mvnw test -Dtest=com.example.MyFailingTest#myMethod` to focus output.
02Atlas reads the `JUnit 5` assertion and the Quarkus production code it exercises, then uses the `lsp` tool's `goToDefinition` and `findReferences` operations to walk the call path through `CDI beans` and `JAX-RS resources`.
03Atlas forms a hypothesis about the bug and checks it by adding temporary logging with the `edit` tool to a Quarkus service, or by re-running the test via `bash` with a verbose flag like `-Dquarkus.log.level=DEBUG` in `application.properties`.
04Atlas fixes the production code in `src/main/java` using `edit` for small changes or `apply_patch` for multi-hunk modifications, ensuring the fix addresses the root cause, not just the `JUnit 5` assertion.
05Atlas re-runs the single `JUnit 5 (@QuarkusTest)` to confirm the fix, then executes the full `Maven` test suite (`./mvnw test`) to check for regressions, and removes any temporary logging added earlier.
06Atlas presents a unified diff of all changes for approval, then applies `Spotless` formatting via `./mvnw spotless:apply` before staging and creating a commit on your behalf.

Frequently asked questions

How does Atlas run only one specific Quarkus test?: Atlas uses its `bash` tool to execute `Maven` with the `-Dtest` flag, targeting a specific `JUnit 5 (@QuarkusTest)` class or method. For example, it might run `./mvnw test -Dtest=com.example.MyServiceTest#myMethod` to isolate the failing test.
Can Atlas debug issues related to Quarkus build-time augmentation?: Yes, Atlas understands the context of Quarkus's build-time augmentation. While debugging, it focuses on fixing the underlying Java code that influences the augmented output, rather than the generated code itself, ensuring compatibility with native-image constraints.
How does Atlas navigate complex Quarkus dependency graphs?: Atlas leverages its `lsp` tool, which understands Java's type system and `CDI` annotations like `@Inject`. It can perform `goToDefinition` and `findReferences` to trace dependencies between `CDI beans` and `JAX-RS resources` within your Quarkus project.
What if my Quarkus test requires specific `application.properties` settings for debugging?: Atlas's `bash` tool can re-run `Maven` tests with additional system properties or modify `application.properties` using `edit` to temporarily adjust logging levels (e.g., `-Dquarkus.log.level=DEBUG`) or other configurations relevant to the test.
How does Atlas ensure code quality after a fix in Quarkus?: After applying a fix, Atlas ensures code quality by invoking `Spotless` via `Maven` (`./mvnw spotless:apply`) before committing. This automatically formats the modified Java files according to your project's defined standards, maintaining consistency.
Does Atlas support `RestAssured` tests in Quarkus?: Yes, Atlas can read and understand `RestAssured` tests written for `JUnit 5 (@QuarkusTest)`. It can trace calls from `RestAssured` assertions back to the `JAX-RS resources` they exercise, using `lsp` to work through the relevant code paths.
How does Atlas handle reviewing proposed changes in a Quarkus project?: Atlas provides a unified diff for every proposed file edit, which you must approve before it writes to disk. All tool calls are permission-gated, and Atlas drafts a plan in a read-only agent for your review before executing any changes to your Quarkus codebase.

Try Atlas in your terminal

The terminal-native AI coding agent. Free core, single binary.

Install Atlas

Related guides

Debug a Single Failing Test with Atlas in 2026

How to debug one failing test with Atlas in 2026: run it in isolation with bash, walk the call graph with the lsp tool, and fix the code, not the assertion.

Atlas for Quarkus in 2026

Atlas is a terminal-native AI coding agent for Quarkus in 2026. It reads CDI beans and JAX-RS resources, then runs ./mvnw test behind a permission prompt.

Self-review your working diff before committing in Quarkus with Atlas in 2026

Catch your own mistakes in uncommitted Quarkus diffs using Atlas. Integrate with Maven, JUnit 5 (@QuarkusTest), and Spotless for a robust self-review workflow.

Review a Quarkus Pull Request with Atlas in 2026

Review Quarkus pull requests with Atlas in 2026. Atlas uses AI to analyze diffs, run JUnit 5 (@QuarkusTest) tests via Maven, and apply Spotless formatting, catching subtle bugs.

Run the test suite and triage the failures in Quarkus with Atlas in 2026

In 2026, Quarkus developers use Atlas to efficiently run JUnit 5 (@QuarkusTest) suites, parse extensive failure logs, and prioritize distinct root causes for rapid resolution.

Locate where a behavior is implemented in Quarkus with Atlas in 2026

Pinpoint Quarkus behavior implementation with Atlas in 2026. Use semantic search, grep, and LSP to find exact files and symbols in your Maven project, ensuring build-time compatibility and code quality.

Refactor a legacy module in Quarkus with Atlas in 2026

Streamline Quarkus module refactoring in 2026 with Atlas. Safely restructure old code, maintain behavior, and prevent breaking callers using Maven, JUnit 5, and Spotless.

Upgrade a Quarkus Dependency and Fix Breakage with Atlas in 2026

In 2026, Atlas helps Quarkus developers upgrade major dependencies, fixing compile and test failures. It drives Maven, reads compiler output, and repairs code with LSP, ensuring JUnit 5 and Spotless compliance.

Browse this resource hub