为现有PowerShell脚本编写Pester测试的方案咨询

针对你遇到的「加载脚本时会直接执行顶层代码」的问题，核心思路是避免测试时触发实际业务逻辑，具体处理方式分脚本类型而定：

一、包含函数+顶层执行代码的脚本 #

这类脚本优先做轻量重构，既不影响原有功能，又能支持Pester测试：

重构方案 #

把所有顶层执行逻辑封装到一个入口函数，然后在脚本末尾添加判断：只有当脚本被直接运行时才执行该函数，被点源/导入时不执行。示例：

# MyScript.ps1
# 原有代码：导入模块、点源其他脚本、声明变量、定义函数...

# 把原来的顶层执行逻辑封装成函数
function Invoke-CleanOldFiles {
    param(
        [string]$TargetPath = "C:\Logs",
        [int]$DaysOld = 30
    )
    # 原有删除逻辑
    Get-ChildItem -Path $TargetPath -Recurse | 
        Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-$DaysOld) } |
        Remove-Item -Force
}

# 仅当脚本直接运行时执行逻辑，被点源时跳过
if ($MyInvocation.InvocationName -ne '.') {
    Invoke-CleanOldFiles
}

测试时，点源MyScript.ps1只会加载函数和依赖，不会执行删除操作。你可以用Pester的Mock命令模拟Get-ChildItem和Remove-Item，安全验证逻辑：

# MyScript.Test.ps1
BeforeAll {
    . $PSScriptRoot/MyScript.ps1
}

Describe "Invoke-CleanOldFiles" {
    It "should filter files older than specified days" {
        Mock Get-ChildItem {
            # 返回模拟的文件对象，其中一个是31天前的，一个是29天前的
            [PSCustomObject]@{
                LastWriteTime = (Get-Date).AddDays(-31)
                FullName = "C:\Logs\old.log"
            },
            [PSCustomObject]@{
                LastWriteTime = (Get-Date).AddDays(-29)
                FullName = "C:\Logs\new.log"
            }
        }
        Mock Remove-Item {}

        Invoke-CleanOldFiles -DaysOld 30

        # 验证Remove-Item只被调用一次（仅删除old.log）
        Assert-MockCalled Remove-Item -Exactly 1
    }
}

过渡方案（暂不重构） #

如果暂时无法修改原脚本，可以在测试前Mock所有会产生实际影响的cmdlet（比如Remove-Item），再点源脚本。但这种方式风险高，容易遗漏未预期的顶层操作，仅作为临时手段：

BeforeAll {
    Mock Remove-Item {}
    Mock Get-ChildItem { @() } # 返回空集合避免匹配到真实文件
    . $PSScriptRoot/MyScript.ps1
}

二、纯顶层代码的脚本（无函数） #

这类脚本必须重构，否则无法安全、精准地测试：

重构步骤 #

1. 将代码拆分为单一职责的小函数，比如文件筛选、删除操作分别封装；
2. 把硬编码的变量改为函数参数，提升灵活性；
3. 添加脚本直接运行的判断逻辑。

示例重构后的脚本：

# MyScript.ps1
# 封装筛选逻辑
function Get-OldFiles {
    param(
        [Parameter(Mandatory)]
        [string]$Path,
        [Parameter(Mandatory)]
        [int]$DaysOld
    )
    Get-ChildItem -Path $Path -Recurse -File |
        Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-$DaysOld) }
}

# 封装删除逻辑
function Remove-TargetFiles {
    param(
        [Parameter(ValueFromPipeline)]
        [System.IO.FileInfo]$File
    )
    process {
        $File | Remove-Item -Force
    }
}

# 原顶层逻辑改为函数调用，仅直接运行时执行
if ($MyInvocation.InvocationName -ne '.') {
    $config = @{
        Path = "C:\Logs"
        DaysOld = 30
    }
    Get-OldFiles @config | Remove-TargetFiles
}

测试时可以分别验证两个函数的逻辑，比如测试Get-OldFiles的筛选规则，测试Remove-TargetFiles是否正确处理输入文件。

三、不导入主脚本直接测试的弊端 #

不建议跳过导入脚本直接测试「内部功能」：

• 你需要复制原脚本的逻辑到测试文件，原脚本更新后测试代码必须同步修改，维护成本极高；
• 无法验证脚本的依赖关系（比如导入的模块、点源的脚本是否正常加载），测试覆盖不完整；
• 容易出现测试逻辑与实际代码不一致的情况，导致测试失效。

总结 #

优先选择重构脚本，将逻辑封装为函数并添加运行判断，这是长期可维护的最优方案；对于暂时无法重构的脚本，用Mock关键cmdlet作为过渡，但要尽快推进重构。

内容的提问来源于stack exchange，提问作者tutu