Collect-Input: empty pipeline unwraps to $null for value assertions#2708
Merged
Conversation
docs/assertion-types.md says a value assertion should treat @() from the
pipeline the same as $null (since there is no scalar to unwrap to), and
the existing TODO on line 46 flagged that we did not match that. We
returned @() for both value and collection assertions, which made these
fail:
@() | Should-Be -Expected $null
@() | Should-BeNull
and made this wrongly pass:
@() | Should-NotBeNull
Collect-Input now returns $null when -UnrollInput is set and the
pipeline collected no items. Collection assertions are unchanged: they
still see @().
Updated Should-BeNull test that previously asserted the buggy "fails"
behavior to assert the documented "passes" behavior, and added matching
coverage on Should-Be, Should-NotBeNull, and Collect-Input itself.
Dropped the TODO and the stray code fence in assertion-types.md.
Verified with the full Pester suite: 2174 passed, 0 failed.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
nohwnd
commented
Jun 11, 2026
Answering the review question on pester#2708: clarify and lock how the value assertions handle arrays containing $null. A single-item pipeline of $null (whether produced by $null, @(\), ,\, or @(@(\))) is what PowerShell actually puts on the pipeline: one $null item. With -UnrollInput this collapses to the scalar $null, so all four pass Should-BeNull / Should-Be -Expected \ and fail Should-NotBeNull. A multi-item pipeline (e.g. @(\, \) or 1, \) is a collection of two items, stays as a collection after unrolling, and is therefore not equal to \. Adds tests for Should-Be, Should-BeNull, Should-NotBeNull, and the underlying Collect-Input to make this explicit. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This was referenced Jun 12, 2026
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
1 participant
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.
docs/assertion-types.mdsays a value assertion should treat@()from the pipeline the same as$null(since there is no scalar to unwrap to). The existing TODO on line 46 flagged that we did not actually match that —Collect-Inputreturned@()for both value and collection assertions, which made these fail:and made this wrongly pass:
Collect-Inputnow returns$nullwhen-UnrollInputis set and the pipeline collected no items. Collection assertions are unchanged: they still see@().Updated the
Should-BeNulltest that previously asserted the buggy "fails" behavior to assert the documented "passes" behavior, and added matching coverage onShould-Be,Should-NotBeNull, andCollect-Inputitself. Dropped the TODO and a stray code fence inassertion-types.md.Verified with the full Pester suite: 2174 passed, 0 failed.
Follow-up to #2707.