Suggest to add `Should-Match` to Pester v6

[johlju]

Checklist

• [X] Feature request has a meaningful title
• [X] I have searched the existing issues. See all issues
• [X] I have tested using the latest version of Pester. See Installation and update guide.

Summary of the feature request

Currently the new assertions for Pester v6 does not support regular expression matching like Should -Match or Should -MatchExactly in v5. Suggest adding a command Should-Match and Should-NotMatch, or possibly add a parameter RegularExpression to the commands Should-BeLikeString and Should-NotBeLikeString.

How should it work?

The commands Should-Match and Should-NotMatch should have the same named and positional parameters as the command Should-NotBeLikeString.

It 'Should match regular expression` {
    '[value]' | Should-Match '^\[.+\]$'
}

It 'Should match regular expression` {
    'Should-Match '^\[.+\]$' '[value]'
}

It 'Should match regular expression` {
    'Should-Match -Expected '^\[.+\]$' -Actual '[value]' -CaseSensitive -Because 'must start and end with brackets' 
}

It 'Should match regular expression` {
    'Should-NotMatch -Expected '^\[.+\]$' -Actual 'value' -CaseSensitive -Because 'must not start and end with brackets' 
}

If we reuse existing commands Should-BeLikeString and Should-NotBeLikeString by adding a new switch parameter.

It 'Should match regular expression` {
    '[value]' | Should-BeLikeString '^\[.+\]$' -RegularExpression
}

It 'Should match regular expression` {
    'Should-BeLikeString '^\[.+\]$' '[value]' -RegularExpression
}

It 'Should match regular expression` {
    'Should-BeLikeString -RegularExpression -Expected '^\[.+\]$' -Actual '[value]' -CaseSensitive -Because 'must start and end with brackets' 
}

It 'Should match regular expression` {
    'Should-NotBeLikeString -Expected '^\[.+\]$' -Actual 'value' -CaseSensitive -Because 'must not start and end with brackets'  -RegularExpression
}

[nohwnd]

Yes. This would be Should-MatchString and Should-NotMatchString, to follow the current naming convention.

[nohwnd]

I will try to do some coding this week on this, but can't promise anything.

[DarkLite1]

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..

[fflaten]

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.

[DarkLite1]

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.

[fflaten]

Thanks for the explanation. Let's move this discussion to a separate issue (#2550)