Print mock history

[nohwnd]

Wanted to spend few minutes on this, since I always say that it would be nice to have. LMK what you think before I start polishing it.

I struggle with identifying which mock was or was not invoked, and why, especially when validating that some cmdlet is called with the correct parameters.

describe "a" {

    it "i" {
        Mock Get-Command {  }

        Get-Command -Name Hello
        Get-Command -Name How

        Write-host ">>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>"
        Should -Invoke Get-Command -Times 10
        write-host ( & (Get-Module Pester ) {
            } )
    }

    it "i2" {
        Mock Get-Command {  }

        Get-Command -Name Hello
        Get-Command -Name How

        Write-host ">>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>"
        Should -Invoke Get-Command -ParameterFilter { $name -eq "aaa" }
        write-host ( & (Get-Module Pester ) {
            } )
    }
}

It improves the situation a bit, but to make it really useful, maybe:

• show which mock was invoked somehow (but how? they don't have their own identifiers)
• show what is the filter on the mock we are looking for (it is there in the stack trace, but is that obvious?
• change the way it is printed so it does not look like runnable code, when it might not be runnable
• nice-format the parameters

[HeyItsGilbert]

Would + and - in the front of the matching calls be better? Either way I think putting the identifier at the beginning may help if the commands are super long.

Another nice to have would be identifying where the call came from (e.g. line number, file, etc.). This could be helpful in identifying mocked calls that are similar but for some reason the logic branch didn't hit them.

I wonder (in another PR) if we flipped this on its head, and made it so we could evaluate what would be mocked (so read in the test file first) and then parsed a script and returned a list of mocked (with what criteria passed/failed). I know that would help me for sure. The other nice thing with this is that if we failed to properly mock, we would know that before running potentially system impacting commands.

[nohwnd]

Would + and - in the front of the matching calls be better? Either way I think putting the identifier at the beginning may help if the commands are super long.

+ and - are already used for the test results, I think it is more confusing.

What else shows success or not success , call or not call, that is not + or -?

It should also be easy to grasp and hard misunderstand, and the format should work when there are 0 calls.

Another nice to have would be identifying where the call came from (e.g. line number, file, etc.). This could be helpful in identifying mocked calls that are similar but for some reason the logic branch didn't hit them.

I agree. Seeing where the mock call came from would be nice. There is even more info that can be printed, e.g. why it did not match ( we cannot explain exactly why, but can at least show the filter that was used).

I wonder (in another PR) if we flipped this on its head, and made it so we could evaluate what would be mocked (so read in the test file first) and then parsed a script and returned a list of mocked (with what criteria passed/failed).

I feel like all of this info already is in the debugging log. And it is a lot of info to help you debug mock calls that behave differently than you thought.

The other nice thing with this is that if we failed to properly mock, we would know that before running potentially system impacting commands.

In version 6 the mocks will never fall through to the real command so this is less of a concern, but I see it still apply when you for example don't mock correctly in a module scope. It is hard to protect you from that though, as it means we would have to push mock into every single mock scope (or hijack the execution).

[nohwnd]

trying your suggestions

[nohwnd]

I think I need to add the location (describe / it) from where the mock came probably?

(Get-AllMockBehaviors is probably the right place where to attach the block / test to the behavior, so we can later get the description from that.)

[HeyItsGilbert]

• and - are already used for the test results, I think it is more confusing.

Yea that makes sense. Plus +/- being pass fail makes more sense that as a signifier in this situation. How about this?

Performed invocations:
  [ ]: $Name-Hello from...
  [*]: $Name-Hello from...