PowerShell 项目测试指南CI 标签体系、Pester/xUnit 框架与本地测试运行规范【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell本文系统梳理 PowerShellPowerShell Core/7开源仓库的官方测试指南。作为横跨 Windows / Linux / macOS 的跨平台项目PowerShell 通过 Azure DevOps 持续集成CI驱动近十万级历史测试与持续增长的 GitHub 测试集。读完本文你将掌握 Pester / xUnit 两套测试框架的分工与适用场景、CI/Scenario/Feature/SLOW等 Pester 标签的语义与使用时机、如何利用[Feature]/[Package]commit 前缀请求 CI 额外执行专项测试以及如何在本地使用build.psm1中的Start-PSPester/Start-PSxUnit复现 CI 测试流程并按仓库规范把新增测试放到正确的目录位置。测试在 PowerShell 项目中的定位Testing 是 PowerShell 项目关键且必需critical and required的一环。官方文档 testing-guidelines.md 明确说明微软 PowerShell 团队在过去的 12 年自 2003 年立项以来累计创建了近 100,000 个测试并作为 Windows PowerShell 发布流程的一部分持续运行将这些测试全部纳入 PowerShell 首个跨平台开源版本并不现实因此项目优先移植那些最有助于在改动最大的区域捕获回归的测试项目意图是持续分批开放更多历史测试直到达到所需的覆盖度因此在仓库中可以看到大量围绕引擎、语言与各内置模块的测试文件详见 test/powershell 目录它们共同构成 PowerShell 发布前的质量门禁。CI 系统与测试结果的获取入口PowerShell 使用Azure DevOps此前曾与 AppVeyor 等系统配合作为 Windows 与非 Windows 平台的持续集成系统。在仓库根目录 README.md 顶部可以看到 Azure CI 徽章badge它表示master分支最近一次构建的状态这个徽章是可点击的点击后可以进入对应的构建页面查看日志logs、产物artifacts与测试结果test results并可从该页面继续导航到完整的构建历史。从 PR 页面获取 CI 结果CI 系统会在**每一个 Pull RequestPR**上执行构建并运行测试从而给出快速反馈这些绿色对勾与红色叉号同样是可点击的它们会把你带到包含详细失败信息与构建日志的对应页面。这正是仓库在README中围绕 Azure CI badge 保持绿色 所强调的质量文化——每一次合入都先由自动化测试把关。从源码看CI 侧的实际测试编排集中在 tools/ci.psm1。其中会调用Get-PesterTag校验允许的标签集合并在注释中说明Tags must be CI, Feature, Scenario, or Slowtools/ci.psm1随后依据不同TagSet计算ExcludeTag分别以普通权限 / 管理员权限两遍执行 Pester 测试。两套测试框架的分工仓库采用脚本测试用 Pester、其余用 xUnit的双框架策略Pester脚本级测试的主力框架Pester 是 PowerShell 生态中最常用的脚本测试框架也是微软内部新增脚本类测试所使用的框架。PowerShell 项目中的大量测试都是从微软内部历史测试库迁移而来的其描述为Pester 可以测试 PowerShell 的绝大多数行为甚至某些 API 操作也能方便地用 Pester 表达为了让 Pester 能在非 Windows 系统上执行PowerShell 团队对其做了实质性改造这些改动当时尚未合入 Pester 官方代码库因此某些 Pester 特性可能不可用或行为有偏差遇到问题请到 PowerShell/PowerShell 的 issue 追踪器中反馈而不是 Pester 项目以便团队统一跟进跨平台适配问题。Pester 测试用例以.tests.ps1命名、以Describe/Context/It组织写法示例与命名规范详见配套文档 WritingPesterTests.md。xUnitPester 不易表达时的补充框架对于不适合用 Pester 轻松编写的测试项目选择了xUnit.NET 生态的标准测试框架。这类测试以 C# 编写集中在 test/xUnit对应工程文件 test/xUnit/xUnit.tests.csproj也包含少量面向托管 API 的宿主级测试如 test/hosting/test_HostingBasic.cs。当前 xUnit 测试在整个测试体系中的占比很小属于补充角色。Pester 测试标签决定你的测试在哪一阶段运行Pester 允许对Describe块打标签tag而CI 系统正是依赖这些标签来决定调用哪些测试。新增测试的Describe块必须使用以下三个标签之一标签含义运行时机CI该Describe中的测试将作为 CI / PR 流程的一部分执行应类似单元测试、单例执行通常在 1 秒以内每个 PR / 每次 CI 构建Scenario更大规模的测试涉及多个功能区域交互和/或远程资源也是每日运行Feature不会在 CI / PR 流程中执行但会在cron 驱动的每日构建中运行通常用于验证更多行为或使用远程网络资源例如包管理类测试每日构建此外还有一个辅助标签标签含义SLOW标记执行时间较长的测试。数据基准是97% 的CI标签测试执行耗时 ≤ 100ms任何耗时超过 1 秒的测试都应考虑打上SLOW标签配套的 WritingPesterTests.md 进一步强调若不提供上述任一标签构建过程将直接失败If the tag is not provided, the build process will fail。源码佐证默认的 Pester 调用入口 Start-PSPester 的参数默认值为Tag (CI,Feature)、ExcludeTag Slowbuild.psm1即本地/CI 常规跑测试时默认执行 CI 与 Feature 两类并排除慢测试而 tools/ci.psm1 中针对不同TagSet会构造类似ExcludeTag (Slow, Feature, Scenario)只跑 CI 标签的过滤规则并在普通权限与管理员权限两个 pass 中分别追加排除或仅选择RequireAdminOnWindows测试tools/ci.psm1。这从实现层面印证了文档中CI 默认只运行CI标签测试的约定。特权类测试的专用标签补充编写测试的官方指引 WritingPesterTests.md 还规定了两种依赖运行特权的标签它们在 CI 中被特殊处理RequireAdminOnWindows在 Windows 上需要管理员权限的测试必须额外打此标签。Azure DevOps Windows CI 会跑两遍一遍排除带RequireAdminOnWindows的测试普通权限一遍只执行带该标签的测试管理员权限RequireSudoOnUnix在 Unix 系统上需要sudo运行的测试必须额外打此标签。该标签优先于CI/Feature等所有其它标签存在时其它标签被忽略此类测试会在任何 Unix 测试中以独立的 pass 运行。Start-PSPester 的实现会自动处理这一约定在非管理员、非 sudo 场景下自动把RequireAdminOnWindows/RequireSudoOnUnix追加到ExcludeTag而在-Sudo场景下自动把 Tag 收紧为RequireSudoOnUnixbuild.psm1。通过 commit message 请求额外 CI 测试CI 常规情况下只运行带CI标签的测试但在最近一次提交描述的第一行添加特殊标记即可改变这一行为[Feature]触发 CI 额外运行带Feature标签的测试。适用场景你新增或修改了一个Feature标签测试维护者要求你运行Feature测试根据经验你确信维护者接下来会要求你运行Feature测试。[Package]默认 CI 对 PR 只做构建 测试不执行打包代码若 PR 涉及打包packaging改动在 commit message 第一行使用[Package]即可让 CI 额外执行打包流程。适用场景你修改了 PowerShell Core 的打包逻辑维护者要求你以[Package]方式运行。这种提交消息触发符机制让贡献者可以在不阻塞 PR 的前提下按需请求更重的验证流水线。在本地复现 CI运行 Pester 与 xUnit 测试开发新功能或修复 bug 时提交 PR 之前通常想先在本地跑一遍 CI 会执行的测试。这些辅助函数随build.psm1模块提供仓库根目录 build.psm1Start-PSPester执行 CI 系统运行的全部 Pester 测试其实现位于 build.psm1Start-PSxUnit执行 CI 系统运行的 xUnit 测试位于 build.psm1。CI 系统本身也是调用它们因此在开发机上运行与在 CI 中运行不应有差异。运行这类测试时请务必以-noprofile启动 PowerShell——某些测试在环境非默认或存在自定义配置时会失败。示例运行全部 CI Pester 测试在 PowerShell 仓库根目录执行Import-Module ./build.psm1 Start-PSPester示例运行指定路径下的测试Start-PSPester -Path test/powershell/engine/Api示例运行单个 Pester 测试文件Start-PSPester -Path test/powershell/engine/Api/XmlAdapter.Tests.ps1实现细节据 build.psm1 的源码未显式传参时Start-PSPester默认扫描test/powershell目录执行 Tag 为CIFeature、排除SLOW的测试并以NUnitXml格式输出到pester-tests.xml便于 CI 归档与展示它要求本机已安装Pester 4.2 及以上版本否则自动调用Restore-PSPesterbuild.psm1完成安装首次运行会调用Publish-PSTestToolsbuild.psm1用dotnet publish构建测试所需的辅助可执行程序如 test/tools/TestExe、test/tools/UnixSocket、test/tools/WebListener、test/tools/TestAlcWindows 下还会构建 test/tools/TestService——这也是测试进程间通信、WebListener、NamedPipe 等场景的必要前置子进程启动时强制携带-noprofile源码中$PSFlags (-noprofile)见 build.psm1与文档要求一致通过-Tag/-ExcludeTag可精确控制要跑的标签集借助-ExperimentalFeatureName可通过临时配置文件为指定测试启用某项实验性功能实验功能与测试文件的映射见 test/tools/TestMetadata.json。PR 合入之后会发生什么当你的 PR 成功通过 CI 测试门禁后你的改动会被用来构建可在微软内部测试框架中运行的 PowerShell 二进制你为改动编写的新测试 庞大的历史测试库都会被运行用于确认是否存在回归regression若这些测试发现回归你会收到PR 尚未就绪的通知并附带足够的失败信息以便排查原因。换言之CI 门禁只是第一道防线合入后的历史测试库回归验证才是最终的质量保险。测试目录布局按功能组织而非按类型堆砌PowerShell 的 Pester 测试采用功能化布局functional approach新增测试应放到合适的位置如果你修复的是某个模块中的 cmdlet测试应放在该模块对应的目录下如果不确定放哪可以随 PR 一起提出或创建一个 issue 请维护者定夺。文档给出的标准测试布局如下路径均相对于仓库根目录test/powershell功能域目录引擎Engineengine、engine/Api、engine/Basic、engine/ETS、engine/Help、engine/Logging、engine/Module、engine/ParameterBinding、engine/Remoting、engine/Runspace、engine/Logging/MessageAnalyzer宿主HostHost、Host/ConsoleHost、Host/TabCompletion语言LanguageLanguage、Language/Classes、Language/Interop、Language/Interop/DotNet、Language/Operators、Language/Parser、Language/Scripting、Language/Scripting/Debugging、Language/Scripting/NativeExecution模块ModulesModules、Modules/Microsoft.PowerShell.Archive、Modules/Microsoft.PowerShell.Core、Modules/Microsoft.PowerShell.Diagnostics、Modules/Microsoft.PowerShell.Management、Modules/Microsoft.PowerShell.Security、Modules/Microsoft.PowerShell.Utility、Modules/PSReadLine其它Provider、SDK、Security目录随版本演进可能略有调整。以当前仓库快照核对test/powershell 顶层实际存在Host、Language、Modules、Provider、SDK、dsc、engine等目录其中 test/powershell/engine 下包含Api、Basic、ETS、Help、Module、ParameterBinding、Remoting等test/powershell/Language 下包含Classes、Interop、Operators、Parser、Scripting等与文档骨架基本一致。提交新测试前建议以仓库当前 master 为准定位目录。编写高质量 Pester 测试的核心原则配套的 WritingPesterTests.md 给出了为该项目编写 Pester 测试的完整指引它不替代 Pester 官方文档而是本项目的实战补充。核心要求摘录如下测试应当极简不要过度复杂、不要一次测试太多东西把测试蒸馏到本质只测你真正需要验证的行为测试之间不应相互依赖每个It块断言单一预期It名称应明确表达期望语句化而非把说明塞进错误信息用Should -Throw -ErrorId断言预期错误它基于FullyQualifiedErrorId与区域无关比依赖错误文案更健壮需要进一步检查InnerException等 ErrorRecord 成员时配合-PassThru善用-TestCases以参数化方式迭代多个数据用例避免复制粘贴It块文件操作一律使用TestDrive:Pester 在临时目录创建的 PSDrive测试结束后由 Pester 自动清理避免产生外部副作用用Mock替代依赖的既有命令让测试不依赖完整环境避免Describe块中的游离代码Pester 对块外代码的执行时机很微妙Describe/Context级BeforeAll可能先于块内其他代码执行应把状态初始化放入BeforeAll/BeforeEach/AfterEach/AfterAll测试必须跨平台避免依赖注册表与 COM不要过度断言资源的精确数量各平台格式文件数量不同而应针对具体类型断言格式数据多用正向表述不要写... shouldnt fail改写为... should be able to ...这类正向断言文件命名描述性测试名.tests.ps1并在Describe上按前述规则打CI/Feature/Scenario标签。延伸测试覆盖度与质量追踪配套文档docs/testing-guidelines目录下还有若干与本文直接相关的配套资料可作纵深参考PowerShellCoreTestStatus.md记录早期 PowerShell Core 各 cmdlet 在 Linux / Windows 的交付与测试覆盖状态统计TestRoadmap.md测试体系演进路线图讨论代码覆盖、每日全量测试、pending/skipped 测试追踪、跨平台远程remoting测试矩阵与发布标准等治理议题getting-code-coverage.mdWindows 下借助 OpenCover 运行覆盖率分析、用Get-CodeCoverage/Compare-CodeCoverage/Compare-FileCoverage查看与对比覆盖数据并用 ReportGenerator 生成可视化 HTML 报告的完整流程对应工具模块位于 test/tools/OpenCover仓库 codecov.yml 亦可佐证覆盖率持续追踪机制。小结PowerShell 的测试体系可以概括为三条主线框架上以 Pester 为主、xUnit 为辅调度上完全依赖CI/Scenario/Feature/SLOW以及特权专用的RequireAdminOnWindows/RequireSudoOnUnix标签配合[Feature]、[Package]提交前缀实现按需的 CI 重跑落地方式上本地通过 build.psm1 的Start-PSPester/Start-PSxUnit即可 1:1 复现 CI 行为而新增测试按 test/powershell 的功能化布局放置即可与既有测试库共同承担回归防护。掌握这套约定无论你是为引擎修复提交补丁还是为某个 cmdlet 补测试都能让代码以与官方 CI 完全一致的标准通过质量门禁。【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
PowerShell 项目测试指南CI 标签体系、Pester/xUnit 框架与本地测试运行规范【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell本文系统梳理 PowerShellPowerShell Core/7开源仓库的官方测试指南。作为横跨 Windows / Linux / macOS 的跨平台项目PowerShell 通过 Azure DevOps 持续集成CI驱动近十万级历史测试与持续增长的 GitHub 测试集。读完本文你将掌握 Pester / xUnit 两套测试框架的分工与适用场景、CI/Scenario/Feature/SLOW等 Pester 标签的语义与使用时机、如何利用[Feature]/[Package]commit 前缀请求 CI 额外执行专项测试以及如何在本地使用build.psm1中的Start-PSPester/Start-PSxUnit复现 CI 测试流程并按仓库规范把新增测试放到正确的目录位置。测试在 PowerShell 项目中的定位Testing 是 PowerShell 项目关键且必需critical and required的一环。官方文档 testing-guidelines.md 明确说明微软 PowerShell 团队在过去的 12 年自 2003 年立项以来累计创建了近 100,000 个测试并作为 Windows PowerShell 发布流程的一部分持续运行将这些测试全部纳入 PowerShell 首个跨平台开源版本并不现实因此项目优先移植那些最有助于在改动最大的区域捕获回归的测试项目意图是持续分批开放更多历史测试直到达到所需的覆盖度因此在仓库中可以看到大量围绕引擎、语言与各内置模块的测试文件详见 test/powershell 目录它们共同构成 PowerShell 发布前的质量门禁。CI 系统与测试结果的获取入口PowerShell 使用Azure DevOps此前曾与 AppVeyor 等系统配合作为 Windows 与非 Windows 平台的持续集成系统。在仓库根目录 README.md 顶部可以看到 Azure CI 徽章badge它表示master分支最近一次构建的状态这个徽章是可点击的点击后可以进入对应的构建页面查看日志logs、产物artifacts与测试结果test results并可从该页面继续导航到完整的构建历史。从 PR 页面获取 CI 结果CI 系统会在**每一个 Pull RequestPR**上执行构建并运行测试从而给出快速反馈这些绿色对勾与红色叉号同样是可点击的它们会把你带到包含详细失败信息与构建日志的对应页面。这正是仓库在README中围绕 Azure CI badge 保持绿色 所强调的质量文化——每一次合入都先由自动化测试把关。从源码看CI 侧的实际测试编排集中在 tools/ci.psm1。其中会调用Get-PesterTag校验允许的标签集合并在注释中说明Tags must be CI, Feature, Scenario, or Slowtools/ci.psm1随后依据不同TagSet计算ExcludeTag分别以普通权限 / 管理员权限两遍执行 Pester 测试。两套测试框架的分工仓库采用脚本测试用 Pester、其余用 xUnit的双框架策略Pester脚本级测试的主力框架Pester 是 PowerShell 生态中最常用的脚本测试框架也是微软内部新增脚本类测试所使用的框架。PowerShell 项目中的大量测试都是从微软内部历史测试库迁移而来的其描述为Pester 可以测试 PowerShell 的绝大多数行为甚至某些 API 操作也能方便地用 Pester 表达为了让 Pester 能在非 Windows 系统上执行PowerShell 团队对其做了实质性改造这些改动当时尚未合入 Pester 官方代码库因此某些 Pester 特性可能不可用或行为有偏差遇到问题请到 PowerShell/PowerShell 的 issue 追踪器中反馈而不是 Pester 项目以便团队统一跟进跨平台适配问题。Pester 测试用例以.tests.ps1命名、以Describe/Context/It组织写法示例与命名规范详见配套文档 WritingPesterTests.md。xUnitPester 不易表达时的补充框架对于不适合用 Pester 轻松编写的测试项目选择了xUnit.NET 生态的标准测试框架。这类测试以 C# 编写集中在 test/xUnit对应工程文件 test/xUnit/xUnit.tests.csproj也包含少量面向托管 API 的宿主级测试如 test/hosting/test_HostingBasic.cs。当前 xUnit 测试在整个测试体系中的占比很小属于补充角色。Pester 测试标签决定你的测试在哪一阶段运行Pester 允许对Describe块打标签tag而CI 系统正是依赖这些标签来决定调用哪些测试。新增测试的Describe块必须使用以下三个标签之一标签含义运行时机CI该Describe中的测试将作为 CI / PR 流程的一部分执行应类似单元测试、单例执行通常在 1 秒以内每个 PR / 每次 CI 构建Scenario更大规模的测试涉及多个功能区域交互和/或远程资源也是每日运行Feature不会在 CI / PR 流程中执行但会在cron 驱动的每日构建中运行通常用于验证更多行为或使用远程网络资源例如包管理类测试每日构建此外还有一个辅助标签标签含义SLOW标记执行时间较长的测试。数据基准是97% 的CI标签测试执行耗时 ≤ 100ms任何耗时超过 1 秒的测试都应考虑打上SLOW标签配套的 WritingPesterTests.md 进一步强调若不提供上述任一标签构建过程将直接失败If the tag is not provided, the build process will fail。源码佐证默认的 Pester 调用入口 Start-PSPester 的参数默认值为Tag (CI,Feature)、ExcludeTag Slowbuild.psm1即本地/CI 常规跑测试时默认执行 CI 与 Feature 两类并排除慢测试而 tools/ci.psm1 中针对不同TagSet会构造类似ExcludeTag (Slow, Feature, Scenario)只跑 CI 标签的过滤规则并在普通权限与管理员权限两个 pass 中分别追加排除或仅选择RequireAdminOnWindows测试tools/ci.psm1。这从实现层面印证了文档中CI 默认只运行CI标签测试的约定。特权类测试的专用标签补充编写测试的官方指引 WritingPesterTests.md 还规定了两种依赖运行特权的标签它们在 CI 中被特殊处理RequireAdminOnWindows在 Windows 上需要管理员权限的测试必须额外打此标签。Azure DevOps Windows CI 会跑两遍一遍排除带RequireAdminOnWindows的测试普通权限一遍只执行带该标签的测试管理员权限RequireSudoOnUnix在 Unix 系统上需要sudo运行的测试必须额外打此标签。该标签优先于CI/Feature等所有其它标签存在时其它标签被忽略此类测试会在任何 Unix 测试中以独立的 pass 运行。Start-PSPester 的实现会自动处理这一约定在非管理员、非 sudo 场景下自动把RequireAdminOnWindows/RequireSudoOnUnix追加到ExcludeTag而在-Sudo场景下自动把 Tag 收紧为RequireSudoOnUnixbuild.psm1。通过 commit message 请求额外 CI 测试CI 常规情况下只运行带CI标签的测试但在最近一次提交描述的第一行添加特殊标记即可改变这一行为[Feature]触发 CI 额外运行带Feature标签的测试。适用场景你新增或修改了一个Feature标签测试维护者要求你运行Feature测试根据经验你确信维护者接下来会要求你运行Feature测试。[Package]默认 CI 对 PR 只做构建 测试不执行打包代码若 PR 涉及打包packaging改动在 commit message 第一行使用[Package]即可让 CI 额外执行打包流程。适用场景你修改了 PowerShell Core 的打包逻辑维护者要求你以[Package]方式运行。这种提交消息触发符机制让贡献者可以在不阻塞 PR 的前提下按需请求更重的验证流水线。在本地复现 CI运行 Pester 与 xUnit 测试开发新功能或修复 bug 时提交 PR 之前通常想先在本地跑一遍 CI 会执行的测试。这些辅助函数随build.psm1模块提供仓库根目录 build.psm1Start-PSPester执行 CI 系统运行的全部 Pester 测试其实现位于 build.psm1Start-PSxUnit执行 CI 系统运行的 xUnit 测试位于 build.psm1。CI 系统本身也是调用它们因此在开发机上运行与在 CI 中运行不应有差异。运行这类测试时请务必以-noprofile启动 PowerShell——某些测试在环境非默认或存在自定义配置时会失败。示例运行全部 CI Pester 测试在 PowerShell 仓库根目录执行Import-Module ./build.psm1 Start-PSPester示例运行指定路径下的测试Start-PSPester -Path test/powershell/engine/Api示例运行单个 Pester 测试文件Start-PSPester -Path test/powershell/engine/Api/XmlAdapter.Tests.ps1实现细节据 build.psm1 的源码未显式传参时Start-PSPester默认扫描test/powershell目录执行 Tag 为CIFeature、排除SLOW的测试并以NUnitXml格式输出到pester-tests.xml便于 CI 归档与展示它要求本机已安装Pester 4.2 及以上版本否则自动调用Restore-PSPesterbuild.psm1完成安装首次运行会调用Publish-PSTestToolsbuild.psm1用dotnet publish构建测试所需的辅助可执行程序如 test/tools/TestExe、test/tools/UnixSocket、test/tools/WebListener、test/tools/TestAlcWindows 下还会构建 test/tools/TestService——这也是测试进程间通信、WebListener、NamedPipe 等场景的必要前置子进程启动时强制携带-noprofile源码中$PSFlags (-noprofile)见 build.psm1与文档要求一致通过-Tag/-ExcludeTag可精确控制要跑的标签集借助-ExperimentalFeatureName可通过临时配置文件为指定测试启用某项实验性功能实验功能与测试文件的映射见 test/tools/TestMetadata.json。PR 合入之后会发生什么当你的 PR 成功通过 CI 测试门禁后你的改动会被用来构建可在微软内部测试框架中运行的 PowerShell 二进制你为改动编写的新测试 庞大的历史测试库都会被运行用于确认是否存在回归regression若这些测试发现回归你会收到PR 尚未就绪的通知并附带足够的失败信息以便排查原因。换言之CI 门禁只是第一道防线合入后的历史测试库回归验证才是最终的质量保险。测试目录布局按功能组织而非按类型堆砌PowerShell 的 Pester 测试采用功能化布局functional approach新增测试应放到合适的位置如果你修复的是某个模块中的 cmdlet测试应放在该模块对应的目录下如果不确定放哪可以随 PR 一起提出或创建一个 issue 请维护者定夺。文档给出的标准测试布局如下路径均相对于仓库根目录test/powershell功能域目录引擎Engineengine、engine/Api、engine/Basic、engine/ETS、engine/Help、engine/Logging、engine/Module、engine/ParameterBinding、engine/Remoting、engine/Runspace、engine/Logging/MessageAnalyzer宿主HostHost、Host/ConsoleHost、Host/TabCompletion语言LanguageLanguage、Language/Classes、Language/Interop、Language/Interop/DotNet、Language/Operators、Language/Parser、Language/Scripting、Language/Scripting/Debugging、Language/Scripting/NativeExecution模块ModulesModules、Modules/Microsoft.PowerShell.Archive、Modules/Microsoft.PowerShell.Core、Modules/Microsoft.PowerShell.Diagnostics、Modules/Microsoft.PowerShell.Management、Modules/Microsoft.PowerShell.Security、Modules/Microsoft.PowerShell.Utility、Modules/PSReadLine其它Provider、SDK、Security目录随版本演进可能略有调整。以当前仓库快照核对test/powershell 顶层实际存在Host、Language、Modules、Provider、SDK、dsc、engine等目录其中 test/powershell/engine 下包含Api、Basic、ETS、Help、Module、ParameterBinding、Remoting等test/powershell/Language 下包含Classes、Interop、Operators、Parser、Scripting等与文档骨架基本一致。提交新测试前建议以仓库当前 master 为准定位目录。编写高质量 Pester 测试的核心原则配套的 WritingPesterTests.md 给出了为该项目编写 Pester 测试的完整指引它不替代 Pester 官方文档而是本项目的实战补充。核心要求摘录如下测试应当极简不要过度复杂、不要一次测试太多东西把测试蒸馏到本质只测你真正需要验证的行为测试之间不应相互依赖每个It块断言单一预期It名称应明确表达期望语句化而非把说明塞进错误信息用Should -Throw -ErrorId断言预期错误它基于FullyQualifiedErrorId与区域无关比依赖错误文案更健壮需要进一步检查InnerException等 ErrorRecord 成员时配合-PassThru善用-TestCases以参数化方式迭代多个数据用例避免复制粘贴It块文件操作一律使用TestDrive:Pester 在临时目录创建的 PSDrive测试结束后由 Pester 自动清理避免产生外部副作用用Mock替代依赖的既有命令让测试不依赖完整环境避免Describe块中的游离代码Pester 对块外代码的执行时机很微妙Describe/Context级BeforeAll可能先于块内其他代码执行应把状态初始化放入BeforeAll/BeforeEach/AfterEach/AfterAll测试必须跨平台避免依赖注册表与 COM不要过度断言资源的精确数量各平台格式文件数量不同而应针对具体类型断言格式数据多用正向表述不要写... shouldnt fail改写为... should be able to ...这类正向断言文件命名描述性测试名.tests.ps1并在Describe上按前述规则打CI/Feature/Scenario标签。延伸测试覆盖度与质量追踪配套文档docs/testing-guidelines目录下还有若干与本文直接相关的配套资料可作纵深参考PowerShellCoreTestStatus.md记录早期 PowerShell Core 各 cmdlet 在 Linux / Windows 的交付与测试覆盖状态统计TestRoadmap.md测试体系演进路线图讨论代码覆盖、每日全量测试、pending/skipped 测试追踪、跨平台远程remoting测试矩阵与发布标准等治理议题getting-code-coverage.mdWindows 下借助 OpenCover 运行覆盖率分析、用Get-CodeCoverage/Compare-CodeCoverage/Compare-FileCoverage查看与对比覆盖数据并用 ReportGenerator 生成可视化 HTML 报告的完整流程对应工具模块位于 test/tools/OpenCover仓库 codecov.yml 亦可佐证覆盖率持续追踪机制。小结PowerShell 的测试体系可以概括为三条主线框架上以 Pester 为主、xUnit 为辅调度上完全依赖CI/Scenario/Feature/SLOW以及特权专用的RequireAdminOnWindows/RequireSudoOnUnix标签配合[Feature]、[Package]提交前缀实现按需的 CI 重跑落地方式上本地通过 build.psm1 的Start-PSPester/Start-PSxUnit即可 1:1 复现 CI 行为而新增测试按 test/powershell 的功能化布局放置即可与既有测试库共同承担回归防护。掌握这套约定无论你是为引擎修复提交补丁还是为某个 cmdlet 补测试都能让代码以与官方 CI 完全一致的标准通过质量门禁。【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
