# Debug a Single Failing Test in Quarkus with Atlas in 2026 > Atlas helps Quarkus developers debug single failing tests by running them in isolation with `Maven` and `JUnit 5`, then using `lsp` to trace the code path. 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. ## Key takeaways - Atlas uses `bash` to run specific `JUnit 5 (@QuarkusTest)` methods with `Maven`'s `-Dtest` flag. - The `lsp` tool navigates Quarkus `CDI beans` and `JAX-RS resources` to trace call graphs. - Atlas can insert temporary logging or adjust `application.properties` via `edit` and `bash` for debugging. - Code fixes are applied with `edit` or `apply_patch`, followed by `Spotless` formatting. - All Atlas actions are permission-gated, with unified diffs for review and approval in Quarkus projects. ## 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. ## Steps 1. Atlas 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. 2. Atlas 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`. 3. Atlas 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`. 4. Atlas 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. 5. Atlas 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. 6. Atlas 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. ## FAQ ### 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. --- Canonical HTML: https://runatlas.sh/resources/stacks/debug-a-failing-test-in-quarkus Source of truth: aeo_pages row `/resources/stacks/debug-a-failing-test-in-quarkus` (segment: Stacks) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.