Changes $configuration.Run.PassThru to $True#52
Merged
Conversation
Before Pester V5, the -PassThru parameter was used. We could either use the -PassThru parameter, or set the run configuration in the Configuration Parameter.
devblackops
approved these changes
Aug 12, 2021
Merged
HeyItsGilbert
added a commit
that referenced
this pull request
Oct 6, 2024
### Changed - Bump Pester to latest 5.6.1 ### Fixed - [**#52**](#52) Pester object wasn't being passed back after running tests, causing the Pester task to never fail (via [@webtroter](https://github.com/webtroter)) - [**#55**](#55) Add `-Module` parameter to `Build-PSBuildUpdatableHelp` (via [@IMJLA](https://github.com/IMJLA)) - [**#60**](#60) Fix Windows PowerShell compatibility in `Initialize-PSBuild` (via [@joshooaj](https://github.com/joshooaj)) - [**#62**](#62) Fix code coverage output fle format not working (via [@OpsM0nkey](https://github.com/OpsM0nkey))
5 tasks
tablackburn
added a commit
that referenced
this pull request
Jul 7, 2026
Test-PSBuildPester gated pass/fail only on FailedCount, so a BeforeAll/AfterAll that threw or a test file that errored during discovery left the count at zero and the build passed despite tests never running. Gate on the run's aggregate Result property instead, which Pester derives from all failure categories. Also switch this repo's own psakeFile.ps1 Pester gate (the three-counter sum from #128) to the same Result check so both gates share one definition of "failed". Companion to #128. Same bug lineage as #31, #52, and #57.
tablackburn
pushed a commit
that referenced
this pull request
Jul 10, 2026
Add tests/Test-PSBuildPester.tests.ps1 (#102). Every invocation runs in a Start-Job subprocess with a pinned inner Pester version, and the scenarios run against both installed Pester majors (5.x and 6.x) to verify the shipped function keeps supporting Pester 5 consumers. Crash fixtures are generated into $TestDrive at runtime, never checked in. Scenarios: healthy suite, failing test (regression #52), BeforeAll crash and discovery crash (#128/#133 gate), NUnit result output, and code coverage output path/format (regression Add a second, named Pester dependency (PesterLegacy, 5.9.0) to requirements.psd1 so CI installs both majors side by side. Fix two latent Test-PSBuildPester bugs the tests exposed, test-first (all 14 tests failed before the fixes, pass after): - The finally block called Remove-Module with an empty -Name when the optional ModuleName parameter was omitted, raising a parameter- binding error that -ErrorAction SilentlyContinue cannot suppress. - An unconditional Import-Module Pester -MinimumVersion 5.0.0 loaded the newest installed Pester on top of an already-loaded one, which crashes with a Pester.dll version conflict when two versions are installed side by side. The function now respects a loaded Pester (with a clear error below 5.0.0) and imports the newest installed version only when none is loaded. Closes #102 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011semwa5HU1BUKKL4RoWjKa
4 tasks
tablackburn
added a commit
that referenced
this pull request
Jul 10, 2026
) Add tests/Test-PSBuildPester.tests.ps1 (#102). Every invocation runs in a Start-Job subprocess with a pinned inner Pester version, and the scenarios run against both installed Pester majors (5.x and 6.x) to verify the shipped function keeps supporting Pester 5 consumers. Crash fixtures are generated into $TestDrive at runtime, never checked in. Scenarios: healthy suite, failing test (regression #52), BeforeAll crash and discovery crash (#128/#133 gate), NUnit result output, and code coverage output path/format (regression #62). Pester 5.9.0 is installed side by side with 6.0.0 through the new install-only requirements.pester-matrix.psd1; the bootstrap must not import it, because importing two Pester majors into one session crashes with a Pester.dll version conflict. Fix two latent Test-PSBuildPester bugs the tests exposed, test-first: - The finally block called Remove-Module with an empty -Name when the optional ModuleName parameter was omitted, raising a parameter- binding error that -ErrorAction SilentlyContinue cannot suppress. - An unconditional Import-Module Pester -MinimumVersion 5.0.0 loaded the newest installed Pester on top of an already-loaded one. The function now respects a loaded Pester (with a clear error below 5.0.0) and imports the newest installed version only when none is loaded. Closes #102
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Before Pester V5, the -PassThru parameter was used.
We could either use the -PassThru parameter, or set the run configuration in the Configuration Parameter.
Description
Currently, the Pester task never really fails, because Invoke-Pester doesn't PassThru
Related Issue
#51
Motivation and Context
Before the migration to PesterV5, the PassThru parameter was used, and the replacement in V5 was set to false in the PSBuild Task
How Has This Been Tested?
Changing it in my machine makes the task fail as it should.
Types of changes
Checklist: