Can Atlas write fuzz tests for Solidity contracts?

Yes, Atlas can write fuzz tests for Solidity contracts. It is capable of drafting fuzz tests in the `test/` directory and running them using `forge test` behind a permission prompt, matching existing project conventions.

How does Atlas handle Solidity package dependencies like `soldeer`?

Atlas is designed to operate within Foundry projects and understands dependencies installed by `soldeer`. It can read the libraries installed by `forge soldeer install` and incorporate them correctly into new Solidity test files or contract modifications.

Does Atlas check Solidity gas costs for new tests or contract changes?

Yes, Atlas checks Solidity gas costs. After making changes, Atlas can run `forge snapshot` to show you the gas delta before you approve the modifications, providing transparency on the economic impact of your code.

What Solidity test frameworks does Atlas support?

Atlas is specifically designed to work within Foundry projects, which use `forge test` as their primary test runner. It understands and replicates the conventions of Foundry's Solidity testing framework.

How does Atlas ensure my Solidity code stays private and secure?

Atlas ensures privacy and security by building its code index with local Ollama embeddings, keeping your Solidity code off third-party servers. Additionally, every Atlas tool call is permission-gated, and all file edits require explicit approval via unified diffs.

Can Atlas refactor existing Solidity code, not just add tests?

Yes, Atlas can refactor existing Solidity code. For example, you can ask Atlas to add a reentrancy guard to a contract or convert a `require` string to a custom error to optimize deploy size, always with diffs for approval.

What happens if `forge test` output is very long when run by Atlas?

If the `forge test` output exceeds 2000 lines or 50 KB, Atlas truncates the display in the terminal. However, the full log is saved to a file that you can read, ensuring no information is lost during the testing process.

Write Unit Tests for Untested Solidity Code with Atlas in 2026

Atlas helps Solidity developers in 2026 add real unit tests to untested modules by integrating directly with the Foundry toolchain, including `forge test` for execution, `soldeer` for package management, and `forge fmt` for formatting, ensuring tests match existing repository conventions. This process involves reading the target module, copying existing test styles, writing the new spec, and then running the tests with Atlas's `bash` tool.

How does Atlas identify Solidity test conventions and untested modules?

Atlas identifies existing Solidity test conventions and public functions in 2026 by leveraging its `grep` and `lsp` tools. It first searches for existing test files in the `test/` directory to understand the project's framework and naming, then uses `lsp` to enumerate all public symbols in the target `src/` contract.

To add new unit tests for a Solidity module that currently lacks them, Atlas begins by understanding the existing codebase's testing style. It uses the `grep` tool to search for existing test files, typically within the `test/` directory, to identify the repository's preferred framework, import style, and naming conventions. For instance, it might look for `import {Test} from "forge-std/Test.sol";` to confirm a Foundry-based setup. Concurrently, Atlas employs the `lsp` tool's `documentSymbol` operation on the target Solidity contract in the `src/` directory. This operation provides a comprehensive list of all exported symbols, ensuring that every public function within the module is accounted for and targeted for testing. This dual approach guarantees that new tests are both comprehensive and consistent with the project's established Solidity development practices, which are often defined within a `foundry.toml` configuration.

How to write new Solidity unit tests with Atlas?

Writing new Solidity unit tests with Atlas involves using the `write` tool to draft the test file, typically in the `test/` directory, by copying existing conventions. Atlas ensures that the new test file, such as `test/MyNewContract.t.sol`, adheres to the project's established `forge test` structure, often including 1-2 example tests.

Once Atlas has identified the existing test conventions and the public functions requiring tests, it proceeds to write the new Solidity unit test file. The `write` tool is central to this step, allowing Atlas to generate a new file, for example, `test/MyNewContract.t.sol`. Atlas drafts the content of this file by replicating the framework, import statements, and naming conventions observed in existing test files. This ensures immediate consistency with the project's `forge test` setup. Before any changes are committed to disk, Atlas presents a unified diff for the new test file, allowing the developer to review and approve the proposed additions. For larger modules, Atlas can maintain a `todowrite` list, breaking down the test creation into manageable chunks and ensuring no public function is overlooked during the test writing process.

How to run and iterate on Solidity tests with Atlas?

Running and iterating on Solidity tests with Atlas is managed through the `bash` and `edit` tools, directly invoking `forge test`. Atlas executes `forge test` to identify failures, then uses `edit` to refine the test code, repeating this cycle until all 0 tests pass. Output exceeding 2000 lines or 50 KB is saved to a file for full review.

After drafting the new Solidity unit tests, the crucial step is to execute them. Atlas uses the `bash` tool to run the `forge test` command, targeting the newly created test file, for example, `forge test --match-path test/MyNewContract.t.sol`. This execution reveals any failures or issues in the newly written tests. Atlas captures the output from `forge test`; if the output exceeds 2000 lines or 50 KB, it truncates the display but saves the full log to a file for detailed inspection. Upon identifying failures, Atlas employs the `edit` tool to modify the test file, allowing for rapid iteration and debugging. This cycle of running `forge test` and editing the test file continues until the entire test suite passes, ensuring the new tests are robust and accurate. Atlas also integrates `forge snapshot` to show gas deltas before approval and `forge fmt` to ensure the diff is properly formatted.

How does Atlas ensure safe Solidity test changes and review?

Atlas ensures safe Solidity test changes by presenting a unified diff for every file edit and requiring explicit approval before writing to disk. All tool calls, including `forge test` and `forge snapshot`, are permission-gated, providing a 3-step review process for gas costs and attack surface before any changes land in the 2026 codebase.

Safety and review are paramount when modifying Solidity code, where every diff can impact gas costs and attack surface. Atlas incorporates several mechanisms to ensure that adding new unit tests is a secure and transparent process. Every file edit proposed by Atlas, including the creation of new test files or modifications during iteration, is presented as a unified diff for the developer's review. No changes are written to disk without explicit approval. Furthermore, every Atlas tool call, such as `bash` executing `forge test` or `forge snapshot`, is permission-gated against allow, ask, and deny rules. This means developers are prompted before any command runs, providing granular control. Atlas also leverages `forge snapshot` to compute and display the gas delta associated with any proposed changes, offering critical insights into the economic impact of the Solidity code modifications before they are approved and committed using Atlas's `git` integration.

Step by step

01Use `atlas lsp documentSymbol src/MyContract.sol` to enumerate all public functions in the Solidity module under test.
02Run `atlas grep "import {Test}" test/` to find an existing Solidity test file and copy its framework, import style, and naming convention.
03Draft the new Solidity test file, e.g., `test/NewModule.t.sol`, using `atlas write test/NewModule.t.sol`, reviewing the unified diff for approval.
04Execute the new Solidity tests with `atlas bash "forge test --match-path test/NewModule.t.sol"` and read the failures.
05Iterate on the test file using `atlas edit test/NewModule.t.sol` to fix failures, repeating until the `forge test` suite is green.
06Run `atlas bash "forge snapshot"` to see the gas delta of the changes before final approval.
07Format the new Solidity test file with `atlas bash "forge fmt test/NewModule.t.sol"` to match project standards.
08Approve the final diffs presented by Atlas and use its `git` integration to stage and create a commit.

Frequently asked questions

Can Atlas write fuzz tests for Solidity contracts?: Yes, Atlas can write fuzz tests for Solidity contracts. It is capable of drafting fuzz tests in the `test/` directory and running them using `forge test` behind a permission prompt, matching existing project conventions.
How does Atlas handle Solidity package dependencies like `soldeer`?: Atlas is designed to operate within Foundry projects and understands dependencies installed by `soldeer`. It can read the libraries installed by `forge soldeer install` and incorporate them correctly into new Solidity test files or contract modifications.
Does Atlas check Solidity gas costs for new tests or contract changes?: Yes, Atlas checks Solidity gas costs. After making changes, Atlas can run `forge snapshot` to show you the gas delta before you approve the modifications, providing transparency on the economic impact of your code.
What Solidity test frameworks does Atlas support?: Atlas is specifically designed to work within Foundry projects, which use `forge test` as their primary test runner. It understands and replicates the conventions of Foundry's Solidity testing framework.
How does Atlas ensure my Solidity code stays private and secure?: Atlas ensures privacy and security by building its code index with local Ollama embeddings, keeping your Solidity code off third-party servers. Additionally, every Atlas tool call is permission-gated, and all file edits require explicit approval via unified diffs.
Can Atlas refactor existing Solidity code, not just add tests?: Yes, Atlas can refactor existing Solidity code. For example, you can ask Atlas to add a reentrancy guard to a contract or convert a `require` string to a custom error to optimize deploy size, always with diffs for approval.
What happens if `forge test` output is very long when run by Atlas?: If the `forge test` output exceeds 2000 lines or 50 KB, Atlas truncates the display in the terminal. However, the full log is saved to a file that you can read, ensuring no information is lost during the testing process.

Try Atlas in your terminal

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

Install Atlas

Related 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.

Automate GitHub Issue and Pull Request Triage in Solidity with Atlas in 2026

Automate GitHub issue and pull request triage for Solidity projects using Atlas. Safely respond to PRs and issues in 2026, ensuring trusted users and proper context handling with Foundry.

Audit a Solidity Repo with Parallel Subagents in Atlas, 2026

Sweep your Solidity repository for common problems using Atlas's parallel subagents. Identify issues in Foundry projects without blowing your context window, ensuring secure smart contracts.

Document a module with a README in Solidity with Atlas in 2026

In 2026, Atlas helps Solidity developers generate accurate READMEs for smart contracts. It uses `forge test`, `soldeer`, and `forge fmt` to reflect current code behavior.

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

Solidity developers in 2026 can use Atlas to diagnose whether a `forge test` or `forge soldeer install` command is genuinely slow or silently blocked on input, and get it unstuck.

Add a Regression Test for a Solidity Bug Fix with Atlas in 2026

Lock in Solidity bug fixes with Atlas by adding regression tests. Learn how Atlas uses `forge test` to confirm failures and passes, ensuring robust smart contract development in 2026.

Rename a symbol across the repo in Solidity with Atlas in 2026

Rename Solidity functions, classes, or constants across your entire repository with Atlas. Leverage precise LSP references and `forge test` verification for safe, accurate refactoring in 2026.

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

Catch your own Solidity mistakes before they reach review or CI. Atlas helps you self-review uncommitted diffs in Foundry projects, integrating with forge test and forge fmt.

Browse this resource hub