When the inputs and outputs of a function are being repetitively tested, the TestCases parameter of It can be used. Test cases are defined in a hashtable, which is splatted into It as a set of parameters.

The four test cases used in the preceding example might be rewritten as follows:

$testCases = @( 
    @{ Value = 1;  ExpectedResult = 1 } 
    @{ Value = 4;  ExpectedResult = 2 } 
    @{ Value = 9;  ExpectedResult = 33 } 
    @{ Value = 16; ExpectedResult = 44 } 
) 
 
It 'Calculates the square root of <Value>to be<ExpectedResult>' -TestCases $testCases { 
    param ( 
        $Value, 
        $ExpectedResult 
    ) 
 
    Get-SquareRoot $Value | Should -Be $ExpectedResult 
} 

The preceding tests still contain errors; the advantage of this approach is that Pester will report success or failure for each of the test cases individually:

Describing Get-SquareRoot
[+] Returns a square root of 0 for a value of 0 37ms
[+] Calculates the square root of 1 to be 1 20ms
[+] Calculates the square root of 4 to be 2 11ms
[-] Calculates the square root of 9 to be 33 16ms
Expected: {33}
But was: {3}
at <ScriptBlock>, : line 41
41: Get-SquareRoot $Value | Should Be $ExpectedResult
[-] Calculates the square root of 16 to be 44 35ms
Expected: {44}
But was: {4}
at <ScriptBlock>, : line 41
41: Get-SquareRoot $Value | Should Be $ExpectedResult

Pester automatically replaces values enclosed in angular braces (< and &amp;gt;) with names from the hashtable describing each test case.

Using test cases can save time spent debugging code and tests, as fewer runs are needed to highlight problems.