Would like more info from Assert-MockCalled failures

[msorens]

A typical failure from Assert-MockCalled is:
"Expected xyz in module abc to be called at least 1 times but was called 0 times"

Working from just that sparse information, though, to find the root cause is quite the challenge! It would be a boon to be able to get some details akin to what the moq framework puts out for an analogous error in .NET code:

Expected invocation on the mock once, but was 0 times: 
    x => x.Execute("foobar", .expectedVersion)
Performed invocations:
    IFrobEnabler.Execute("name604d9152", "f997060d-e3eb")

That is, it reports not just the expected method but the arguments that were expected with it AND what was in fact actually called. In my experience with Assert-MockCalled it is rarely the case that a given method is not called; rather it is not called with what the ParameterFilter was configured for. Thus, in a sense, Pester is telling an untruth when it says "expected xyz to be called but it was not" when it really means that "expected xyz with arguments a & b to be called but it was instead called with a & c".

[dlwyatt]

This shouldn't be a problem to add. Thanks for the feedback! :)

[dlwyatt]

Hmm, the PowerShell version of this output can get extremely wordy, with named parameters and deep object graphs. We can still add it, but it might be pretty ugly.

[alx9r]

@brantb was using Should for this purpose. It turns out that Should should never have worked in that situation. Nevertheless, the exception Should throws really does report helpful information.

FWIW, I did some experimentation with a function with semantics similar to a C++ VERIFY macro. A call to Assert-MockCalled would look like

        It 'multiple expressions, second line' {
            Assert-MockCalled f 1 {
                ($a -eq 1 | Verify) -and
                ($b -eq 1 | Verify) -and
                ($b-1 -eq $a | Verify)
            }
        }

and the output looks like

The output seems to provide adequate information to get straight to the line in the parameter filter that failed.

I'm not particularly happy with how many characters it takes to express this. It seems like that aspect could be improved upon.

[japj]

@nohwnd is this still something on the roadmap?

I just ran into this, while trying to figure out why a test was failing for me (using Pester 5.0.4)

[nohwnd]

@japj are you after the list of performed invocations or the Should capability?