# Debug a single failing test in Symfony with Atlas in 2026 > Atlas helps Symfony developers debug a single failing `PHPUnit (WebTestCase)` test by isolating it, walking the call graph, and fixing the production code with precision. To debug a single failing test in Symfony, Atlas isolates the specific `PHPUnit (WebTestCase)` test using `bash` and the framework's `--filter` flag, then employs its `lsp` tool to work through the call graph, and finally uses `edit` or `apply_patch` to fix the underlying production code, not the assertion. This process ensures a focused, efficient debugging experience within your familiar Symfony environment. ## Key takeaways - Atlas isolates single `PHPUnit (WebTestCase)` tests in Symfony using `bash` and `--filter`. - The `lsp` tool in Atlas navigates Symfony's service container and Doctrine entities via `goToDefinition` and `findReferences`. - Atlas validates bug hypotheses by adding temporary logging with `edit` or using verbose `bash` commands. - Production code fixes in Symfony are applied with `edit` or `apply_patch`, with full diff approval. - Atlas ensures safety with permission-gated tool calls and git patch snapshots for Symfony changes. - The entire debugging workflow for Symfony is terminal-native and fully auditable. ## How Atlas isolates a failing Symfony PHPUnit test Debugging a single failing test in Symfony with Atlas begins by isolating the specific `PHPUnit (WebTestCase)` test. Atlas uses its `bash` tool to execute just that one test, leveraging `bin/phpunit --filter` to focus the output, ensuring a clear view of the 1 assertion failure without the noise of the full test suite. When a `PHPUnit (WebTestCase)` test fails in your Symfony application, Atlas doesn't run the entire suite. Instead, it uses its `bash` tool to execute only the problematic test. This is achieved by constructing a precise `bin/phpunit` command, often including the `--filter` flag to target a specific test method or class, for example: `bin/phpunit --filter 'App\Tests\Controller\MyControllerTest::testUserCreationFails'`. This approach mirrors how a Symfony developer would manually isolate a test, providing a familiar and efficient starting point. The output from `PHPUnit` is then directly available to Atlas, allowing it to read the assertion failure and any stack traces, which are crucial for understanding the initial symptoms of the bug. Atlas's ability to run real shell commands means it can interact with your Symfony project exactly as you would, respecting your `composer.json` dependencies and `config/services.yaml` configurations. ## Navigating Symfony code with Atlas's LSP tool After identifying a failing `PHPUnit (WebTestCase)` assertion, Atlas leverages its `lsp` tool to work through the Symfony codebase, tracing the execution path from the test to the production code. This involves using `goToDefinition` to jump to method implementations and `findReferences` to understand how services are used across controllers and injected services, providing a 360-degree view of the code. Once Atlas has the output of the failing `PHPUnit` test, it uses its `read` tool to examine the test file itself and the module it exercises. To understand *why* the test fails, Atlas then employs its `lsp` tool, which integrates with your local language server protocol server. This allows Atlas to perform operations like `goToDefinition` to jump from a method call in a controller to its actual implementation in an autowired service, or from a Doctrine entity method to its definition. It can also use `findReferences` to see where a particular service or method is invoked across your Symfony bundles. This is critical for understanding the flow of data and control within a complex Symfony application, especially when dealing with the service container and Doctrine entity mappings. By walking the call graph, Atlas can pinpoint the exact line of production code responsible for the incorrect behavior, rather than just the failing assertion in the test. ## Forming and checking hypotheses in Symfony with Atlas With a clear understanding of the failing `PHPUnit (WebTestCase)` test and the relevant Symfony code, Atlas forms a hypothesis about the bug. It then checks this hypothesis by adding temporary logging or re-running the test with verbose flags, using its `edit` and `bash` tools. This iterative process helps confirm the root cause before committing to a fix, often involving 1 or 2 rounds of verification. After analyzing the test and walking the call graph, Atlas drafts a plan in its read-only plan agent, forming a hypothesis about the underlying bug in the Symfony production code. To validate this hypothesis, Atlas can use its `edit` tool to temporarily insert logging statements into your controllers, services, or Doctrine entities. For example, it might add `dump()` or `logger->info()` calls to track variable values at critical points. Alternatively, it can re-run the single `PHPUnit` test using `bash` with additional verbose flags, such as `bin/phpunit -v` or specific Symfony debug flags, to get more detailed output. Every Atlas tool call is permission-gated, meaning you approve these temporary changes or command executions. This iterative process of hypothesizing, modifying, and re-running allows Atlas to confirm the exact cause of the failure before proceeding to a permanent fix, ensuring accuracy and preventing misdiagnoses common in complex Symfony applications. ## Fixing Symfony production code and ensuring safety with Atlas Once the root cause of a failing `PHPUnit (WebTestCase)` test is confirmed, Atlas fixes the Symfony production code using its `edit` or `apply_patch` tools. Atlas ensures safety by computing a unified diff for every file edit and surfacing it for approval, and it can snapshot file changes as git patches, allowing for easy rollback of any 1 change. With a confirmed hypothesis, Atlas proceeds to fix the production code in your Symfony application. For small, focused changes, Atlas uses its `edit` tool to modify specific lines in files like controllers, services, or Doctrine entities. If the fix spans several hunks or involves multiple files, Atlas can use `apply_patch` to apply a more comprehensive set of changes, which is less brittle than chaining multiple `edit` commands. Before any changes are written to disk, Atlas computes a unified diff for every file edit and presents it to you for approval. This permission-gated approach ensures you have full control and visibility over every modification. Furthermore, Atlas snapshots file changes as git patches, allowing you to easily diff edits and roll back any unwanted changes, providing a robust safety net. After applying the fix, Atlas will re-run the single `PHPUnit` test to confirm the fix, then the full test suite to ensure no regressions were introduced, and finally remove any temporary logging added during the debugging process. ## Atlas's review and safety mechanisms for Symfony development Atlas integrates several safety mechanisms into its workflow for Symfony development, ensuring that all changes are reviewed and approved. Every Atlas tool call is permission-gated, requiring explicit allow, ask, or deny rules before execution. This includes running `bin/console doctrine:migrations:diff` or applying `PHP-CS-Fixer` over a diff, giving you 100% control. Atlas is designed with developer control and safety at its core, especially crucial when modifying a complex Symfony codebase. Before Atlas executes any tool call, whether it's running a `bash` command like `bin/console doctrine:migrations:diff` or applying an `edit` to a service, it checks against your defined allow, ask, and deny rules. This means you explicitly approve actions, preventing unintended modifications. When Atlas proposes a code change, it always computes a unified diff and presents it for your approval before writing to disk. This allows you to review the exact changes to your controllers, services, or entity mappings. Atlas also reads git branches, status, and diffs, and can stage and create commits on your behalf, or snapshot file changes as git patches for easy rollback. This comprehensive review process, combined with its ability to build its code index with local Ollama embeddings, ensures your code remains secure and off third-party servers, providing peace of mind for Symfony developers in 2026. ## Steps 1. 1. Ask Atlas to run the failing `PHPUnit (WebTestCase)` test using `bash` and the `--filter` flag, for example: `atlas bash 'bin/phpunit --filter "App\\Tests\\Controller\\MyControllerTest::testUserCreationFails"'`. 2. 2. Instruct Atlas to `read` the failing test file and the relevant Symfony production code module it exercises, such as a controller or an autowired service. 3. 3. Use Atlas's `lsp` tool with `goToDefinition` and `findReferences` to walk the call graph from the failing assertion back through your Symfony services and Doctrine entities to pinpoint the exact line of code causing the issue. 4. 4. Form a hypothesis about the bug and ask Atlas to check it by adding temporary logging (e.g., `dump()` statements) with `edit`, or by re-running the test with verbose flags via `bash`. 5. 5. Once the root cause is confirmed, ask Atlas to fix the production code using `edit` for small changes or `apply_patch` for more extensive modifications across your Symfony codebase. 6. 6. After the fix, instruct Atlas to re-run the single `PHPUnit (WebTestCase)` test to confirm the bug is resolved, then run the full `PHPUnit` suite to check for regressions. 7. 7. Finally, ask Atlas to remove any temporary logging statements you added during the debugging process using `edit`. 8. 8. Have Atlas run `PHP-CS-Fixer` over the diff of your changes to ensure code style consistency before committing. ## FAQ ### How does Atlas handle Symfony's service container during debugging? Atlas uses its `lsp` tool to understand the relationships within Symfony's service container. It can `goToDefinition` of injected services and `findReferences` to see where they are used, helping trace the flow of control and data through your autowired services and controllers. ### Can Atlas debug a `WebTestCase` in Symfony? Yes, Atlas is fully capable of debugging `PHPUnit (WebTestCase)` tests in Symfony. It uses `bash` to execute `bin/phpunit` commands, including `--filter` flags, to isolate and run specific web tests, then analyzes their output to identify failures. ### What Symfony-specific commands can Atlas run? Atlas can run any Symfony-specific command via its `bash` tool, including `bin/console` commands like `bin/console doctrine:migrations:diff`, `bin/phpunit` for testing, and `vendor/bin/php-cs-fixer` for code formatting, all with your explicit permission. ### How does Atlas ensure code quality after a fix in Symfony? After fixing a bug, Atlas can be instructed to run `PHP-CS-Fixer` over the modified files or the entire diff. This ensures that any changes adhere to your project's coding standards, maintaining code quality within your Symfony application. ### Is it safe to let Atlas modify my Symfony codebase? Yes, Atlas is designed with safety in mind. Every proposed code change is presented as a unified diff for your approval before being written to disk. All tool calls are permission-gated, and Atlas can snapshot file changes as git patches, allowing for easy rollback of any modifications to your Symfony project. ### Can Atlas help with Doctrine entity debugging in Symfony? Absolutely. Atlas can use its `lsp` tool to navigate Doctrine entity mappings and methods, helping you understand how data is persisted and retrieved. It can also add temporary logging to entity methods via `edit` to inspect values during runtime, aiding in debugging ORM-related issues in Symfony. ### How does Atlas integrate with my existing Symfony development environment? Atlas is terminal-native and integrates direct with your existing Symfony development environment. It reads your `composer.json`, `config/services.yaml`, and other project files, and uses your local `PHPUnit`, `Composer`, and `PHP-CS-Fixer` installations, making it a natural extension of your workflow in 2026. --- Canonical HTML: https://runatlas.sh/resources/stacks/debug-a-failing-test-in-symfony Source of truth: aeo_pages row `/resources/stacks/debug-a-failing-test-in-symfony` (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.