Upgrade Process-PSModule to Pester 6.1 (#519)
Implemented in Process-PSModule
- Enforce the Pester
[6.1.0,7.0.0)range in reusable framework test runs. - Align module-local workflow inputs with the current Invoke-Pester contract:
Version/Prereleaseselect Pester, whileGitHubVersion/GitHubPrereleaseselect the GitHub module. Pester prerelease remains at the action default. - Keep the six Test-PSModule container/test files inside the action implementation at
.github/actions/Test-PSModule/src/tests, because they are context-dependent framework suites executed against the compiled module or source tree. Discovery remains$PSScriptRoot/tests/$settings. - Add a framework CI contract test that validates Pester 6.1 configuration properties:
Run.ShuffleRun.ShuffleSeedRun.ParallelRun.ParallelThrottleLimitDebug.ShowStartMarkers
- Align coverage input documentation with Pester 6.1: supported formats are JaCoCo and Cobertura, and profiler-based tracing is documented correctly.
- Update Pester 6.1 authoring and coverage-report guidance.
Pester 6.1 runtime audit
A local Pester 6.1 probe generated a passing test result and coverage report, and the Get-PesterCodeCoverage action processed that JSON successfully. The coverage result shape remains compatible: CoveragePercent, CoveragePercentTarget, CommandsMissed, CommandsExecuted, FilesAnalyzed, and all count properties are present and consumed correctly.
The Pester result still exposes Containers; each container retains Data, Blocks, and aggregate result/count properties. The existing container files therefore remain compatible with the compiled-module/source-tree execution model.
Contract findings and required upstream follow-up
The current PSModule/Invoke-Pester v5.1.0 action does not expose these Pester configuration properties as action inputs, so this repository deliberately does not add incompatible passthrough mappings:
Run_ShuffleRun_ShuffleSeedRun_ParallelRun_ParallelThrottleLimitDebug_ShowStartMarkers
The coordinated PSModule/Invoke-Pester follow-up must add each input to action.yml, forward each PSMODULE_INVOKE_PESTER_INPUT_* environment variable, map them into the generated PesterConfiguration, and publish a version/tag that Process-PSModule can pin. Process-PSModule can then expose the corresponding reusable-action inputs and pass them through.
Test and fixture boundaries confirmed
- Module-local tests assume the built module is already loaded:
Test-ModuleLocal.ymlimports the artifact in its prescript before invoking Pester. - Framework module tests import the module explicitly in their own test scopes; no implicit preload was introduced.
- PSD1 files in the repository test fixture (
src/data/Config.psd1andsrc/data/Settings.psd1) are not implicitly loaded and are currently unused. Any future PSD1 dataset test must callImport-PowerShellDataFileexplicitly or load it from supported setup. Expose-TestDatapasses only explicit caller-provided fixtures as environment variables to setup, teardown, and tests.- Module linting remains a separate
Invoke-ScriptAnalyzerjob and artifact path; it is not folded into Pester execution.
Validation
- Pester 6.1 configuration contract validated locally.
- Pester 6.1 result/container and coverage shapes inspected locally.
- Get-PesterCodeCoverage executed against a generated Pester 6.1 coverage JSON fixture and passed.
- Restored Test-PSModule scripts parsed successfully.
- Test-PSModule path resolution validated from a consumer repository root.
- Changed PowerShell parsed successfully.
git diff --checkpassed.
Commits: 337533c, ad2961e, 8c3366f, 0423d6a