Enabling Mock to verify invocation sequences

[johndog]

1. General summary of the issue

Conversation starter.

Currently, the documented usage of mock involves verifying that a function gets called a certain number of times, optionally with given set of parameter patterns. There is no way to assert call order, and it is difficult to ensure there are no unintended calls. -ExclusiveFilter would catch unintended calls, but it would appear to only be useful when all calls can match a single pattern.

Consider a function that is a wrapper for Rename-Item, SmartRenameItem. This function's whole job (as with rename-item) is to produce a side-effect of a renamed item, so it can't be tested 'functionally', based on return values.

The proposal is to support the following semantics (syntax not so important, it could be rewritten in terms of filter script blocks):

# Set up context so that original.txt already exists...

It 'gets called with the right parameters in the right order' {
    Mock Rename-Item -VerifiableSequence
    SmartRenameItem original.txt renamed.txt | out-null
    Assert-MockCalled Rename-Item -index 1 with source like "renamed.txt" and destination like "renamed_old.txt"
    Assert-MockCalled Rename-Item -index 2 with source like "original.txt" and destination like "renamed.txt"
    Assert-MockCalled Rename-Item -Times 2
}

An alternative might be to make it possible to query the call sequence such that it can be verified with "Should"s.

2. Describe Your Environment

Pester version : 4.9.0 C:\Program Files\WindowsPowerShell\Modules\Pester\4.9.0\Pester.psd1
PowerShell version : 5.1.19041.1
OS version : Microsoft Windows NT 10.0.19041.0

[nohwnd]

I agree. But imho this is unnecessarily limiting the potential functionality to just the same function (if I get your syntax right), and the verifiablesequence switch seems unnecessary.

Querying the call sequence is imho better, because you can then assert whatever you want, but it should also be easy to use for general cases. Imo we need a prototype for this. The good thing is that this data are already on the result object in pester5 (and deep down there in v4 as well).

Alternatively you could also produce side-effects from your mocks and assert on that simply writing your parameters into a table, which is pretty much how this would work internally as well.