In 2026, Astro developers use Atlas to efficiently add unit tests to untested modules, leveraging existing `vitest` conventions and managing dependencies with `pnpm`. Atlas reads the target module, identifies its exported symbols, and then generates new test files that match the repository's established testing style, ensuring consistency across the codebase.
How does Atlas find untested Astro code and existing test patterns?
Atlas identifies untested Astro code by first reading the target module and then using the `lsp` tool's `documentSymbol` operation to enumerate all exported symbols. This ensures that every public function or component in an Astro file, like `src/components/MyComponent.astro`, is considered for testing, matching the 2026 standard for comprehensive coverage.
To add real tests for a module that has none, Atlas begins by using its `read` tool to ingest the content of the Astro module, such as `src/components/Card.astro`. Following this, the `lsp` tool is invoked with the `documentSymbol` operation. This operation provides a precise list of all exported functions, variables, or components within that Astro file, ensuring no public interface is overlooked. Once the module's exports are known, Atlas uses the `grep` tool to search the existing codebase for an example test file. This search helps Atlas understand the repository's specific `vitest` framework setup, import styles, and naming conventions, such as `src/components/Card.test.ts` or `src/pages/index.test.ts`. By analyzing these existing patterns, Atlas ensures that any new test files it generates will direct integrate with the project's established testing practices, maintaining consistency and readability for Astro developers. This approach prevents Atlas from inventing new conventions and instead adheres strictly to the project's existing `prettier (prettier-plugin-astro)` formatted style.
How does Atlas write new `vitest` spec files for Astro modules?
Atlas writes new `vitest` spec files for Astro modules by first understanding the module's exports and then copying existing repository test conventions. The `write` tool then drafts the new test file, such as `src/components/Button.test.ts`, ensuring it aligns with the project's `prettier (prettier-plugin-astro)` formatting and `vitest` setup, all before any changes are committed to disk in 2026.
After identifying the module's exported symbols and the project's `vitest` testing conventions, Atlas proceeds to write the new spec file. The `write` tool is central to this process. For an Astro component like `src/components/Header.astro`, Atlas might generate a corresponding test file, for example, `src/components/Header.test.ts`. This new file will include `import` statements that mirror the existing test files found via `grep`, and it will structure `vitest` `describe` and `it` blocks according to the established patterns. Before any content is written to disk, Atlas presents a unified diff of the proposed changes. This diff allows the Astro developer to review the generated test code, ensuring it meets their expectations and adheres to the project's specific requirements. This permission-gated prompt is a critical safety feature, giving the developer full control over what changes are applied. Atlas ensures that the generated code is ready for execution by `vitest` and will be formatted correctly by `prettier (prettier-plugin-astro)`.
How does Atlas run `vitest` tests and iterate on failures in Astro projects?
Atlas runs `vitest` tests in Astro projects using the `bash` tool, executing the actual `pnpm test` command to validate newly written specs. If tests fail, Atlas reads the output and uses the `edit` tool to iterate on fixes, saving full logs to a file if output exceeds 2000 lines or 50 KB, ensuring efficient debugging in 2026.
The crucial step in adding real tests is execution. Atlas uses the `bash` tool to run the `vitest` test suite. This typically involves executing the command `pnpm test` or a similar script defined in the `package.json` file of the Astro project. Running the tests immediately provides feedback on the correctness of the newly written specs. If tests fail, Atlas captures the output from the `bash` command. For large test outputs exceeding 2000 lines or 50 KB, Atlas truncates the displayed output in the terminal but saves the full log to a file, which the developer can then inspect. Atlas then uses the `edit` tool to make necessary adjustments to the test file or the module under test. This iterative process of running tests, analyzing failures, and editing code continues until the entire test suite is green. For larger modules or complex test scenarios, Atlas can also leverage the `todowrite` tool to maintain a list of pending tasks, ensuring that progress is tracked and no test cases are missed during the iteration cycle. This ensures that the tests are not just written, but are actually passing and providing value.
What safety and review mechanisms does Atlas provide for Astro code changes?
Atlas provides robust safety and review mechanisms for Astro code changes, ensuring developers maintain full control over every modification. Every Atlas tool call, including `write` and `bash`, is permission-gated against allow, ask, and deny rules, and Atlas computes a unified diff for every file edit, surfacing it for approval before writing, a standard practice in 2026.
Atlas prioritizes developer control and code integrity throughout the testing workflow for Astro projects. Before any tool, such as `write` or `bash`, executes a command that could modify the filesystem or run external processes, Atlas consults its permission-gated rules (allow, ask, deny). This means an Astro developer must explicitly approve actions like writing a new `src/components/MyComponent.test.ts` file or running `pnpm test`. Furthermore, for every file edit Atlas proposes, it computes and displays a unified diff. This diff clearly shows exactly what changes will be made to the Astro codebase, whether it's a new test file, an update to an existing component, or a modification to `astro.config.mjs`. The developer reviews this diff and must approve it before Atlas writes anything to disk. Atlas also snapshots file changes as git patches, allowing edits to be easily diffed and rolled back if needed. This comprehensive review process ensures that all changes, including those formatted by `prettier (prettier-plugin-astro)`, are transparent and fully controlled by the developer, preventing unintended modifications to the Astro project.
Step by step
- 01Run `atlas read src/components/MyComponent.astro` to analyze the module under test and understand its structure.
- 02Execute `atlas lsp documentSymbol src/components/MyComponent.astro` to enumerate all exported symbols, ensuring comprehensive test coverage.
- 03Use `atlas grep "import { test } from 'vitest'"` to find an existing `vitest` test file in your Astro project and identify its conventions.
- 04Draft the new `src/components/MyComponent.test.ts` spec file with `atlas write`, reviewing the unified diff for approval before it lands on disk.
- 05Run the `vitest` suite using `atlas bash "pnpm test"` to execute the newly written tests and observe any failures.
- 06If tests fail, use `atlas edit src/components/MyComponent.test.ts` to iterate on fixes, making adjustments to the test or the Astro component.
- 07Repeat steps 5 and 6 until all `vitest` tests pass, ensuring the module is fully tested.
- 08Let Atlas format the new test file with `prettier (prettier-plugin-astro)` behind a permission prompt to maintain code style consistency.
Frequently asked questions
- How does Atlas ensure new Astro tests match my project's style?
- Atlas uses its `grep` tool to analyze existing `vitest` test files in your Astro project. It identifies your repository's specific import styles, naming conventions, and `prettier (prettier-plugin-astro)` formatting, then applies these patterns when generating new test files.
- Can Atlas add tests for specific Astro components or pages?
- Yes, Atlas can target specific Astro components like `src/components/MyComponent.astro` or pages in `src/pages`. It uses the `read` tool to understand the module and `lsp` to enumerate its exported symbols, ensuring all public interfaces are covered by `vitest` tests.
- What happens if the `vitest` tests Atlas writes fail?
- If `vitest` tests fail after being run by `atlas bash "pnpm test"`, Atlas captures the output. You can then use `atlas edit` to modify the test file or the Astro module under test, iterating until the suite passes.
- Does Atlas modify my Astro code without my permission?
- No, Atlas never modifies your Astro code without explicit permission. Every `write` operation, including creating new `vitest` test files or formatting with `prettier (prettier-plugin-astro)`, presents a unified diff for your review and approval before any changes are applied.
- How does Atlas handle large `vitest` test outputs in Astro projects?
- When `vitest` test outputs exceed 2000 lines or 50 KB, Atlas truncates the terminal display but saves the full log to a file. This allows you to review the complete output for debugging purposes while keeping the terminal clean.
- Can Atlas help me set up `vitest` in a new Astro project?
- While this page focuses on adding tests to *untested* code, Atlas can assist with various Astro setup tasks. It reads `astro.config.mjs` and can help with content collection schemas or integration configurations, but for `vitest` setup, it primarily adapts to existing patterns.
- What package manager does Atlas use for Astro projects?
- Atlas uses `pnpm` as the package manager for Astro projects, executing commands like `pnpm test` via its `bash` tool to run `vitest` test suites and manage dependencies.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Write Unit Tests for Untested Code with Atlas in 2026
How to write unit tests for untested code with Atlas in 2026: the lsp tool enumerates exported symbols, grep copies repo conventions, and bash actually runs the suite.
Atlas for Astro: Islands, Content Collections, and Zero JS by Default in 2026
Atlas is a terminal-native AI coding agent for Astro in 2026. It reads astro.config.mjs, src/pages, and content collection schemas, drops needless client:load directives, and runs astro check.
Upgrade a Dependency and Fix Breakage in Astro with Atlas in 2026
In 2026, Astro developers use Atlas to efficiently upgrade dependencies and resolve compile or test failures. Atlas drives pnpm, fetches changelogs, and fixes code across .astro islands and content collections, ensuring
Self-review your working diff before committing in Astro with Atlas in 2026
Catch your own mistakes in Astro projects before they reach review or CI. Atlas helps Astro developers in 2026 self-review uncommitted diffs, run `vitest` tests, and format code with `prettier (prettier-plugin-astro)`
Plan a Multi-File Change Before Editing in Astro with Atlas in 2026
Design and review complex, multi-file changes in your Astro project before writing a single line of code. Atlas, the terminal-native AI agent, integrates with pnpm, vitest, and prettier (prettier-plugin-astro) to ensure
Audit an Astro Repository with Parallel Subagents in Atlas in 2026
Sweep an entire Astro repository for problems without exceeding your main session's context window using Atlas's parallel subagents. Leverage `pnpm`, `vitest`, and `prettier` for efficient, focused audits.
Automate GitHub Issue and Pull Request Triage in Astro with Atlas for 2026
Automate GitHub issue and pull request triage in your Astro projects with Atlas in 2026. Safely manage contributions, enforce trusted user access, and streamline workflows using `pnpm` and `vitest`.
Extract a Shared Helper from Duplicated Code in Astro with Atlas in 2026
Refactor duplicated logic in your Astro project into a single, tested helper using Atlas. Find semantic duplicates across .astro files, create new modules, and replace copies with calls, all while integrating with