It would be nice to [have an option to] provide test source code snippet on failure

[vors]

I often find myself in a situation, when I cannot express my intention with a pester test.
By express I mean: person who see failed test results should understand what's the matter of failure with the least possible actions.

For example, let's take some binary condition.

Let's say these are my functions:

function Get-SmartFoo() {
    sleep 2
    'foo'
}

function Get-DumbFoo() {
    sleep 1
    'foo'
}

I want to express: Get-SmartFoo should work faster then Get-DumbFoo (which is currently not true).
Here is what I can write:

Describe 'SmartFoo' {

    It 'Return string foo' {
        Get-SmartFoo | Should be 'foo'
    }

    It 'faster then DumbFoo' {
        $smartFooTime = (Measure-Command { Get-SmartFoo }).TotalSeconds
        $dumbFooTime = (Measure-Command { Get-DumbFoo }).TotalSeconds
        $smartFooTime -lt $dumbFooTime | Should Be $true
    }
}

Imagine, you didn't touch test code for a while. Probably, you will go to the source and find the line 20 to see what exactly the code does.

I would prefer to see a code snippet from the failure immediately in the test results.
For instance

With this knowledge, I can write my tests much wiser. I would use meaningful variable names, to provide a context about the failure.

[dlwyatt]

Love it! :) Just need to make sure it works on PowerShell 2.0.

[nohwnd]

@vors Looks great. Maybe no space between the failure and the code? If there is more failed tests it might become confusing.

[vors]

Cool :)

@dlwyatt any ideas, how to do it on 2.0?
@nohwnd good point, will do.

[dlwyatt]

Looks like you're just using JSON as an in-between format to carry an object via a string property (piped to ConvertFrom-Json in Get-PesterResult). Two PS 2.0 compatible options here, that I can think of off the top of my head:

• Don't use a string property; just assign an object to the ErrorRecord.TargetObject property (which we aren't using for pester exceptions anyway)
• Use the string property, but don't use JSON. ConvertTo-Clixml and ConvertFrom-Clixml should work just as well.

[dlwyatt]

Of course, it would be nice if the ConvertTo-Clixml and ConvertFrom-Clixml cmdlets existed. :P I forgot that I have those as functions in my profile. You just need to use [System.Management.Automation.PSSerializer]::Serialize() and [System.Management.Automation.PSSerializer]::Deserialize() to get the same effect.

[dlwyatt]

Which are also not present in PowerShell 2.0. Bah! :) There are technically internal Serializer and Deserializer classes that you can get to with Reflection, but I'd just use TargetObject; less hassle.

[vors]

Fixed in #266