Pester: folder structure

Decided I would go this way. FileUtility is the start… need to get the other utilities aligned with that.







Pester: pretty summaries

Short examples of a mix of passing and failing Pester tests being rendered in a browser, using ReportUnit, available on NuGet, and ingesting NUnit output format. Check out the browser screenshots below first for the end result.


# Runs all test suites, passes the output to the NUnit format, renders it, displays in a browser

# see my article here for installing nuget via Choco:



nuget.exe install ReportUnit

#Then, for example...

# Execute all the tests

$outputName = Get-Random

$outputFile = "$PSScriptRoot/$outputName.xml"

$htmlFile = "$PSScriptRoot/$outputName.html"

Invoke-Pester -PassThru -Strict -OutputFile $outputFile -OutputFormat NUnitXml

.\ReportUnit.1.2.1\tools\ReportUnit.exe $outputFile

Start-Process chrome $htmlFile

PowerShell: proving case insensitivity with Pester

PowerShell, as any fule doth know, is case-insensitive by default. However, I saw this kind of construct the other day:

if ($value -eq "Y" -or $value -eq "y") { ...

Oh dear. But just to prove the point, and as Pester is now Out of the Box on Windows 10:

Pester and PowerShell: TDD

There is obviously nothing special about Pester that encourages you down the TDD route. But assuming you start out with a test structure pattern that works for you, then with some trivial cosmetics, I find it is pretty good fun to do.

An example of some failing tests:

And following a fix to the code under test…

This is my overarching test runner:

For contriving a TDD approach out of this, you could:

clone my repository from GitHub here

From this location, delete the section below, so that you have a test but no SUT for it

When you execute RunAllTests.ps1, you see this:

You can then create nothing but the function name…

and execute RunAllTests.ps1 again…

, and eventually you get to a point when you have fully working code…

… and all tests passing: