Closed splatteredbits closed 3 years ago
Personally, I tend to use Should Throw
in conjunction with -ErrorAction Stop
to do these sorts of tests.
From a general UI standpoint, having an Assert-That
function instead of Should
would be more flexible (and would avoid some headaches that come from using the pipeline as input to Should
). Assert-MockCalled
and Assert-VerifiableMocks
basically exist for that same reason; it wouldn't make any sense to try to shoehorn them into the current implementation of Should
. I could see an Assert-That
command being an eventual replacement for all three of those commands.
However, I would not want to start that work right now from the master branch, because significant changes have already been made to Should
in the https://github.com/pester/Pester/tree/DevelopmentV4 branch. Doing anything out in master would result in another giant merge conflict for me to sort out later, which I'm getting rather sick of doing. I want to get v4 done and released soon. :)
The related project by @nohwnd -> https://github.com/nohwnd/Assert
@dlwyatt, should we close the current issue as 'Feature - refused'?
@splatteredbits does this still sound like a good idea to you?
I currently have custom Assert-Error and Assert-NoError functions. I'd like an equivalent in Pester. Something like:
Why not:
Also, you can't actually use
$Error
, since that collection is scoped. You have to actually use $Global:Error. That can be hard to remember. Encapsulating that in an assertion would be nice.Should I create an
Assert-That
function? Or put these assertions somewhere else? Essentially, I'd like a place for assertions about the system, not necessarily specific objects.