# Write Unit Tests for Untested PowerShell Code with Atlas in 2026 > Atlas enables PowerShell developers to quickly add Pester unit tests to existing PowerShell modules, ensuring all exported cmdlets are covered and adhere to repository conventions. Atlas helps PowerShell developers in 2026 add real unit tests to untested modules by leveraging Pester, PSResourceGet, and PSScriptAnalyzer Invoke-Formatter. It reads your existing code, identifies exported symbols, and then drafts new `.Tests.ps1` files that match your repository's established conventions, ensuring comprehensive coverage and adherence to best practices. ## Key takeaways - Atlas uses `lsp` to find all exported PowerShell symbols for comprehensive Pester testing. - Existing Pester `.Tests.ps1` files guide Atlas in adopting your repo's specific PowerShell testing style. - Every generated PowerShell test file and `Invoke-Pester` run requires your explicit approval via a unified diff. - Atlas integrates `PSScriptAnalyzer Invoke-Formatter` to maintain consistent code style in new PowerShell tests. - You can iterate on failing PowerShell tests directly within Atlas using the `edit` tool. - Atlas keeps your PowerShell code local by building its code index with Ollama embeddings. ## How Atlas Identifies Untested PowerShell Code Atlas identifies untested PowerShell code by first reading your `.psm1` module and then using the `lsp` tool's `documentSymbol` operation to enumerate all exported symbols. This ensures that every public function, cmdlet, or variable in your module, even if there are 50 of them, is considered for test coverage. To begin writing unit tests for an existing PowerShell module, Atlas first needs to understand its structure. It uses the `read` tool to ingest the contents of your `.psm1` module file. Following this, Atlas employs the `lsp` tool with the `documentSymbol` operation to precisely enumerate all exported symbols within that module. This crucial step ensures that Atlas does not miss any public functions, cmdlets, or variables that require testing. By leveraging the Language Server Protocol, Atlas gains a deep, AST-level understanding of your PowerShell code, moving beyond simple keyword searches to identify every testable component, guaranteeing 100% coverage of your module's public interface. ## Matching Existing Pester Test Conventions in PowerShell To ensure new tests integrate direct, Atlas uses the `grep` tool to find existing `.Tests.ps1` files within your repository, learning the specific Pester framework, import styles, and naming conventions. This process ensures that the 10 new test files Atlas generates will look like they were written by your team. A key aspect of integrating new tests into an existing PowerShell codebase is adhering to established conventions. Atlas achieves this by using the `grep` tool to search your repository for existing Pester test files, typically named with the `.Tests.ps1` suffix. Atlas analyzes these files to understand your team's preferred Pester framework usage, module import styles (e.g., `Import-Module` or `using module`), and naming conventions for test suites and individual tests. This intelligent analysis allows Atlas to generate new `.Tests.ps1` files that perfectly match your repository's existing idioms, making the new tests indistinguishable from those written manually and ensuring a consistent, maintainable test suite. ## Writing and Running New PowerShell Unit Tests with Atlas Atlas drafts new Pester `.Tests.ps1` files using its `write` tool, showing a unified diff for approval before any changes are applied to disk. Once approved, Atlas executes the new test suite with the `bash` tool, running `Invoke-Pester` to validate the 0 failures expected. After identifying testable symbols and understanding repository conventions, Atlas proceeds to draft the new Pester unit tests. It uses the `write` tool to generate the `.Tests.ps1` files, presenting a unified diff of the proposed changes for your review. This permission-gated step ensures you have full control and visibility over every line of code Atlas suggests. Once you approve the changes, Atlas writes the files to disk. The next critical step is execution: Atlas uses the `bash` tool to run `Invoke-Pester` against the newly created `.Tests.ps1` files. This immediate execution is vital, as a test that was never run is not a test. Atlas captures the output, truncating logs over 2000 lines or 50 KB but saving the full log to a file for detailed review. If tests fail, you can use the `edit` tool to iterate on the test code, and for larger modules, `todowrite` helps manage progress. ## Ensuring Quality and Safety in PowerShell Test Generation Atlas prioritizes safety and quality in PowerShell test generation, offering permission-gated tool calls and a unified diff for every file edit. This means you review every proposed change, from adding a `CmdletBinding` to a function to running `PSScriptAnalyzer Invoke-Formatter` on a new `.Tests.ps1` file, before it's committed. Atlas is designed with robust safety and quality checks for PowerShell development. Every Atlas tool call, whether it's `read`, `write`, or `bash`, is permission-gated against allow, ask, and deny rules, giving you granular control. Before any file edit, Atlas computes and surfaces a unified diff for your approval, ensuring transparency and preventing unintended changes. This applies to everything from adding `CmdletBinding` and `SupportsShouldProcess` to a destructive function to generating new `.Tests.ps1` files. Atlas also integrates with `PSScriptAnalyzer Invoke-Formatter` to automatically apply formatting standards to new or modified code, ensuring consistency. Furthermore, Atlas reads `git` branches, status, and diffs, and can stage and create commits on your behalf, with file changes snapshotted as `git` patches for easy diffing and rollback, providing a secure and auditable workflow. ## Steps 1. Run `atlas read MyModule.psm1` to understand the module's structure, exported cmdlets, and pinned requirements. 2. Execute `atlas lsp documentSymbol MyModule.psm1` to enumerate all public functions and cmdlets requiring Pester tests. 3. Use `atlas grep -r ".Tests.ps1"` to find existing Pester test files and learn the repository's testing conventions and import styles. 4. Initiate `atlas write MyModule.Tests.ps1` to draft the new Pester test file, reviewing the unified diff for approval before writing to disk. 5. Run the newly generated tests with `atlas bash "Invoke-Pester -Path MyModule.Tests.ps1"` and review the output for failures. 6. If tests fail, use `atlas edit MyModule.Tests.ps1` to iterate on the test code, refining it until the Pester suite is green. 7. Apply PowerShell formatting standards with `atlas bash "PSScriptAnalyzer Invoke-Formatter -Path MyModule.Tests.ps1 -Recurse"`. 8. Approve and commit the new `.Tests.ps1` file using Atlas's `git` integration, ensuring a clean and documented change. ## FAQ ### How does Atlas ensure it tests all PowerShell functions in a module? Atlas uses the `lsp` tool's `documentSymbol` operation on your `.psm1` module to enumerate every exported function and cmdlet, ensuring no public interface is missed when generating Pester tests. ### Can Atlas adapt to my existing Pester test structure and conventions? Yes, Atlas uses `grep` to analyze your current `.Tests.ps1` files, learning your specific Pester framework, import statements, and naming conventions to match new tests direct within your PowerShell repository. ### What specific PowerShell tools does Atlas use for testing and quality? Atlas directly integrates with `Pester` for running tests, `PSResourceGet` for package management, and `PSScriptAnalyzer Invoke-Formatter` for code formatting, leveraging the real PowerShell toolchain. ### How do I review the PowerShell tests Atlas writes before they are saved? Atlas presents a unified diff for every file edit, including new `.Tests.ps1` files, and requires your explicit approval before writing anything to disk, giving you full control over the generated PowerShell code. ### What happens if the generated PowerShell tests fail after Atlas runs them? Atlas runs `Invoke-Pester` via the `bash` tool and surfaces failures. You can then use `atlas edit` to refine the tests until they pass, with `todowrite` available for managing progress on larger PowerShell modules. ### Does Atlas handle PowerShell module dependencies for testing? Yes, Atlas reads your module's requirements and can use `PSResourceGet` to manage dependencies, ensuring the test environment is correctly set up for your PowerShell module's Pester tests. ### Is my PowerShell code sent to third-party servers when using Atlas? No, Atlas can build its code index with local Ollama embeddings, keeping your PowerShell code entirely off third-party servers and ensuring your intellectual property remains secure. --- Canonical HTML: https://runatlas.sh/resources/stacks/write-unit-tests-for-untested-code-in-powershell Source of truth: aeo_pages row `/resources/stacks/write-unit-tests-for-untested-code-in-powershell` (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.