How does Atlas handle NestJS dependency injection during debugging?

Atlas understands NestJS's decorator-driven dependency injection container. When navigating code with `lsp`, it can trace dependencies between providers and modules, helping you understand how services are injected and used, which is crucial for debugging issues related to provider scopes or module imports in `app.module.ts`.

Can Atlas help me debug a NestJS guard or interceptor?

Yes, Atlas can debug NestJS guards and interceptors. You can isolate a test that triggers the guard/interceptor, then use `lsp goToDefinition` to inspect its logic. Atlas can also `edit` the guard/interceptor code to add temporary logging or modify its behavior for debugging purposes, just as you would manually.

What if my NestJS test uses a custom test harness like `Test.createTestingModule`?

Atlas works direct with `Test.createTestingModule` harnesses. When you run a test via `atlas bash`, `jest` executes the test setup as usual. Atlas's `read` and `lsp` tools can then analyze the code within your test setup and the modules it mocks or provides, giving you full context for debugging.

Can Atlas help me understand DTO validation issues in NestJS?

Absolutely. If a test fails due to DTO validation, Atlas can help. You can use `lsp goToDefinition` on your DTOs to inspect their structure and validation decorators. Atlas can also `edit` the DTO or the `ValidationPipe` configuration to temporarily adjust validation rules or add logging to understand why a specific input is failing.

Is Atlas compatible with different NestJS project structures or monorepos?

Atlas builds its code index using AST declarations via tree-sitter, not blind line windows, making it robust across various project structures, including NestJS monorepos. As long as a `nest-cli.json` and `app.module.ts` are present, Atlas can effectively navigate and understand your project's layout, regardless of complexity.

Debug a single failing test in NestJS with Atlas in 2026

To debug a single failing test in NestJS with Atlas, you run the specific test in isolation using `atlas bash` and `jest`'s filtering flags, then use Atlas's `lsp` tool to trace the call graph, form a hypothesis, and fix the production code with `atlas edit` or `apply_patch` before re-running tests and applying `prettier`.

How to isolate a single failing NestJS test with Atlas

Isolating a single failing NestJS test is the first critical step in debugging, and Atlas streamlines this process by leveraging `jest`'s powerful filtering capabilities through its `bash` tool. In 2026, developers can quickly target a specific test, reducing noise and focusing on the exact failure point, often cutting down initial investigation time by 90% or more.

Atlas allows you to run any shell command directly within your terminal, including your NestJS project's test runner, `jest`. Instead of running the entire test suite with `pnpm test`, you instruct Atlas to execute `jest` with specific flags to target only the problematic test. For instance, if a test in `src/users/users.controller.spec.ts` named "should return a user" is failing, you would use `atlas bash pnpm test -- --testPathPattern=src/users/users.controller.spec.ts --testNamePattern="should return a user"`. This command ensures that only the relevant test runs, providing a clean, focused output that Atlas can then analyze. This approach is identical to how a NestJS developer would manually isolate a test, ensuring familiarity and direct control over the debugging environment.

Navigating NestJS code with Atlas's LSP tool

Once a single NestJS test is isolated, understanding the code it exercises is paramount. Atlas's `lsp` tool provides robust code navigation, allowing you to walk the call graph of your NestJS application, from controllers to providers and DTOs, with 100% accuracy. This capability is crucial for tracing the flow of data and logic that leads to a test failure.

Atlas integrates with the Language Server Protocol (LSP) to offer deep insights into your NestJS codebase. After identifying the failing assertion in your `*.spec.ts` file, you can use `atlas lsp goToDefinition` on the relevant function or variable to jump directly to its definition, whether it's in a service, a module, or a DTO. For example, if a test fails when calling `usersService.findOne()`, you can use `goToDefinition` on `findOne` to navigate to `src/users/users.service.ts`. Conversely, `atlas lsp findReferences` helps you see all places where a specific method or class is used, which is invaluable for understanding the impact of potential changes across your `@Module` imports and exports, provider scopes, and decorator-driven dependency injection container. This allows Atlas to understand the intricate relationships between NestJS components, such as how a `ValidationPipe` processes DTOs or where a custom guard is registered.

Forming and testing hypotheses in NestJS with Atlas

After isolating a failing NestJS test and navigating its call graph, forming a hypothesis about the root cause is the next logical step. Atlas empowers you to test these hypotheses rapidly by adding temporary logging or re-running tests with verbose flags, often reducing the feedback loop to under 30 seconds. This iterative process is key to pinpointing the exact line of code responsible for the failure.

Atlas's `edit` tool allows you to insert temporary logging statements directly into your NestJS production code. For instance, if you suspect an issue within `src/users/users.service.ts`, you can use `atlas edit src/users/users.service.ts` to add `console.log()` statements at critical points. After adding the logs, you can re-run the single failing test using `atlas bash pnpm test -- --testPathPattern=src/users/users.controller.spec.ts --testNamePattern="should return a user"` to observe the output. Alternatively, if `jest` or a specific NestJS module offers a verbose flag, you can pass it through `atlas bash` to get more detailed runtime information. This ability to quickly modify code, re-execute, and observe results is fundamental to debugging, allowing you to confirm or refute your hypotheses efficiently without leaving the terminal environment.

Fixing NestJS code and ensuring quality with Atlas

Once the root cause of a failing NestJS test is identified, Atlas facilitates the precise application of fixes to your production code. Whether it's a minor adjustment or a more substantial refactor, Atlas ensures changes are applied correctly and consistently, often integrating with `prettier` to maintain code style across 100% of touched files.

Atlas provides two primary tools for modifying code: `edit` for small, targeted changes and `apply_patch` for more extensive modifications spanning multiple hunks or files. If your fix involves a single line or a small block, `atlas edit src/users/users.service.ts` is ideal. For larger refactors, such as updating a DTO or modifying a provider's interface that affects several files, `atlas apply_patch` can be used to apply a pre-computed patch, ensuring atomicity and reducing the risk of errors. After applying the fix, Atlas prompts you to re-run the single failing test to confirm the fix, then the full test suite (`pnpm test`) to ensure no regressions. Finally, Atlas can automatically run `pnpm prettier --write .` across the touched providers and other files, ensuring your NestJS codebase adheres to your team's formatting standards.

Atlas's safety and review process for NestJS changes

Atlas prioritizes safety and transparency throughout the debugging and code modification process, especially when interacting with a complex framework like NestJS. Every proposed change, from a temporary log to a production code fix, is permission-gated and presented as a unified diff for your approval, giving you 100% control over your codebase.

Before Atlas executes any tool call that modifies your NestJS project, such as `edit` or `apply_patch`, it drafts a plan in a read-only agent and asks for your explicit permission. This permission-gating mechanism ensures that no changes are made without your consent. When Atlas proposes a code modification, it computes a unified diff for every affected file, surfacing it for your review. This allows you to see exactly what changes will be applied to your `app.module.ts`, `nest-cli.json`, or any other NestJS-specific file. Atlas also reads your `git` branches, status, and diffs, and can stage and create commits on your behalf, integrating direct into your existing development workflow. This robust review process, combined with the ability to snapshot file changes as `git` patches for easy rollback, provides a secure and controlled environment for debugging and evolving your NestJS applications.

Step by step

01Run just the failing NestJS test: Use `atlas bash pnpm test -- --testPathPattern=src/path/to/your.spec.ts --testNamePattern="your test description"` to isolate the specific test.
02Read the NestJS test and module: Use `atlas read src/path/to/your.spec.ts` and `atlas read src/path/to/your.service.ts` to understand the assertion and the code it exercises.
03Walk the NestJS call path: Employ `atlas lsp goToDefinition` on key functions (e.g., a provider method) and `atlas lsp findReferences` to trace data flow through NestJS modules and providers.
04Form and check a hypothesis: Add temporary logging with `atlas edit src/path/to/your.service.ts` (e.g., `console.log('Debug value:', value);`) or re-run with verbose flags via `atlas bash`.
05Fix the NestJS production code: Apply the fix using `atlas edit src/path/to/your.service.ts` for small changes, or `atlas apply_patch` for multi-hunk modifications across NestJS components.
06Re-run the single test: Confirm the fix by executing `atlas bash pnpm test -- --testPathPattern=src/path/to/your.spec.ts --testNamePattern="your test description"` again.
07Run the full NestJS test suite: Ensure no regressions by running `atlas bash pnpm test`.
08Remove temporary logging and format: Use `atlas edit` to remove any `console.log` statements, then run `atlas bash pnpm prettier --write .` to ensure code style.

Frequently asked questions

How does Atlas handle NestJS dependency injection during debugging?: Atlas understands NestJS's decorator-driven dependency injection container. When navigating code with `lsp`, it can trace dependencies between providers and modules, helping you understand how services are injected and used, which is crucial for debugging issues related to provider scopes or module imports in `app.module.ts`.
Can Atlas help me debug a NestJS guard or interceptor?: Yes, Atlas can debug NestJS guards and interceptors. You can isolate a test that triggers the guard/interceptor, then use `lsp goToDefinition` to inspect its logic. Atlas can also `edit` the guard/interceptor code to add temporary logging or modify its behavior for debugging purposes, just as you would manually.
What if my NestJS test uses a custom test harness like `Test.createTestingModule`?: Atlas works direct with `Test.createTestingModule` harnesses. When you run a test via `atlas bash`, `jest` executes the test setup as usual. Atlas's `read` and `lsp` tools can then analyze the code within your test setup and the modules it mocks or provides, giving you full context for debugging.
How does Atlas ensure my NestJS code stays formatted after edits?: Atlas integrates with your project's formatter, `prettier`. After making code changes with `edit` or `apply_patch`, Atlas can automatically run `pnpm prettier --write .` across the modified files, ensuring your NestJS codebase adheres to your defined style guidelines without manual intervention.
Can Atlas help me understand DTO validation issues in NestJS?: Absolutely. If a test fails due to DTO validation, Atlas can help. You can use `lsp goToDefinition` on your DTOs to inspect their structure and validation decorators. Atlas can also `edit` the DTO or the `ValidationPipe` configuration to temporarily adjust validation rules or add logging to understand why a specific input is failing.
Is Atlas compatible with different NestJS project structures or monorepos?: Atlas builds its code index using AST declarations via tree-sitter, not blind line windows, making it robust across various project structures, including NestJS monorepos. As long as a `nest-cli.json` and `app.module.ts` are present, Atlas can effectively navigate and understand your project's layout, regardless of complexity.

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.

Audit a NestJS Repository with Parallel Subagents in 2026

Audit your NestJS codebase efficiently in 2026 using Atlas's parallel subagents. Sweep for problems across modules, providers, and DTOs without blowing your context window, leveraging `jest` and `prettier`.

Run Atlas Headless in CI with NestJS in 2026

Automate Atlas sessions in your NestJS CI pipeline for machine-readable output. Learn to configure `atlas run` with `pnpm` and `jest` to integrate AI-driven code changes safely in 2026.

Run the Test Suite and Triage Failures in NestJS with Atlas in 2026

Streamline NestJS test triage in 2026 with Atlas. Turn walls of red `jest` output into prioritized, distinct root causes using `pnpm`, `grep`, and `todowrite`.

Diagnose a Hanging or Long-Running Command in NestJS with Atlas in 2026

Quickly diagnose hanging or slow NestJS commands with Atlas in 2026. Learn to distinguish genuinely slow `pnpm` or `jest` runs from those silently blocked on input, and get your NestJS development unstuck.

Extract a Shared Helper from Duplicated Code in NestJS with Atlas in 2026

Streamline NestJS refactoring in 2026 by extracting shared helpers from duplicated logic using Atlas. Identify semantic duplicates, create new modules, and apply changes with full reviewability, ensuring your NestJS

Refactor a Legacy NestJS Module with Atlas in 2026

Streamline your NestJS codebase in 2026 by refactoring legacy modules with Atlas. Ensure no breaking changes to callers using `jest` and `prettier` for a robust migration.

Review a Pull Request in NestJS with Atlas in 2026

NestJS developers in 2026 can use Atlas to review pull requests, catching subtle bugs by examining full file context, checking signature changes, and running `jest` tests, ensuring robust code quality and preventing

Browse this resource hub