search

pester / Pester

Pester is the ubiquitous test and mock framework for PowerShell.
https://pester.dev/
Other
3.08k stars 470 forks source link

Missing -Not parameter in new Should- assertions #2550

Open fflaten opened 1 month ago

fflaten commented 1 month ago

In Pester v5 I really loved the simplicity of negating a statement:

.. | Should -Invoke Get-Process
.. | Should -Not -Invoke Get-Process

I guess the -Not switch will no longer be used in the future? Really loved that feature though..

Originally posted by @DarkLite1 in https://github.com/pester/Pester/issues/2533#issuecomment-2252270088

The v6 style is currently

# invoke is not implemented yet
.. | Should-Invoke Get-Process
.. | Should-NotInvoke Get-Process

Is that worse? As we're using standalone functions to overcome parameter set max limitation the alternative would be:

.. | Should-Invoke Get-Process
.. | Should-Invoke -Not Get-Process
.. | Should-Invoke Get-Process -Not

The parameter doesn't flow/read as well imo.

Originally posted by @fflaten in https://github.com/pester/Pester/issues/2533#issuecomment-2252338247

I hear what you say, it does read easier but for splatting purposes, the separate -Not argument would be easier. I can imagine TestCases or ForEach where a decision is made to either call the mocked function or not.

Also for inteliSense it would be easier to use one CmdLet name instead of having to type Should-Not.

Originally posted by @DarkLite1 in https://github.com/pester/Pester/issues/2533#issuecomment-2252347148

fflaten commented 1 month ago

I don't disagree on the function bloat and 90% help duplication etc. though we have to find a balance.

Personally I'm struggling a bit with testcases modifying the assertion behavior like Should .. -Not:$SomeTestParam. Maybe it's my personal style, but I'd always have two separate tests for working vs failing, mocked vs not etc. for easier troubleshooting and test naming.

@nohwnd What's your thoughts on the current design for Not/Negate?