Hint that -ExpectedMessage uses wildcards when the message looks identical - #2956
Merged
Conversation
…tical
Should -Throw -ExpectedMessage matches with -like, so [ ] * ? are wildcards.
When the actual message is identical to the expected one except for those
characters, the match fails but the failure message printed the same text on
both sides ("with message like 'X' ... but the message was 'X'"), which is
confusing and bit people migrating from v4 where matching used .Contains.
Add a note in that case pointing at wildcard matching and how to escape.
Fixes pester#1793
🤖
Spell out the whole expected failure message in the test so it is obvious we are matching for the wildcard hint, and move the note before the 'from <path>' location so it reads in order and the test can assert it cleanly. 🤖
fflaten
reviewed
Aug 6, 2026
fflaten
left a comment
fflaten
left a comment
Collaborator
There was a problem hiding this comment.
We need the same for Should-Throw. Maybe make Hint a optional parameter in Fail so we can override the default Get-AssertionGotcha in special cases like this.
| $but = Join-And $buts | ||
| $failureMessage = "Expected an exception$(if($filter) { " with $filter" }) to be thrown,$(Format-Because $Because) but $but. $actualExceptionLine".Trim() | ||
| $wildcardHint = if ($messageFailedOnWildcard) { | ||
| "$([System.Environment]::NewLine) Note: -ExpectedMessage matches using wildcards (-like). The messages are identical except for the wildcard characters [ ] * ? in -ExpectedMessage. Escape them with a backtick (``[) or use [System.Management.Automation.WildcardPattern]::Escape() to match them literally." |
Collaborator
There was a problem hiding this comment.
Use same format as hints in v6 assertions?
"$formattedMessage`n`nHint: $hint"
nohwnd
added a commit
that referenced
this pull request
Aug 11, 2026
* Hint at unescaped wildcards on Should-Throw -ExceptionMessage Should-Throw filters -ExceptionMessage with -like, so [ ] * ? are wildcards. When the actual message is identical to the expected one treated literally, the match fails only because of unescaped wildcard characters, and the two messages look the same in the failure. Detect that case and add a hint, same as the v5 Should -Throw does since #2956. To carry the hint I added an optional Hint key to the ShouldAssertion.Fail data. When present it overrides the default Get-AssertionGotcha hint and is appended with the standard "Hint: <text>" format the other v6 assertions use, so no new formatting path is introduced. Fixes #2968 Fixes #2966 🤖 * Update src/functions/assert/Common/New-ShouldAssertion.ps1 Co-authored-by: Frode Flaten <3436158+fflaten@users.noreply.github.com> --------- Co-authored-by: Frode Flaten <3436158+fflaten@users.noreply.github.com>
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
2 participants
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.
Should -Throw -ExpectedMessagematches with-like, so[ ] * ?are wildcards. When the actual message is identical to the expected one except for those characters, the match fails, but the failure message printed the same text on both sides:Same text on both sides, no hint why it failed. This bites people migrating from v4, where the message match used
.Contains, and it is the cause of a few issues and StackOverflow questions.Now that case adds a note:
The note only shows when the actual message equals the expected one treated literally, so it does not fire on genuine mismatches or on intentional wildcards that just did not match.
Fixes #1793
🤖