Table of Contents – Design Practices

Well, we’ve started Part II; it’s official.

The Design Practices chapter of The Pester Book went a little bit of everywhere, and no surprise really, when you consider the topic. Design practices are going to be a consideration at all points of your Pester authoring. This chapter began with the discussion of tests, and how they are forever. Testing isn’t something we do once, before a final release. It’s something we do before every release. We’ve likely all been troubled by code changes before that ended up doing more harm than good, as a new fix or feature broke previous fixes and features. By continually testing, we can ensure our code modifications only add to the tools we create, as we ensure that previous tests continue to pass.

We learned about being certain, beyond a doubt, that we’re testing the proper script or function, when it’s quite possible that we have more than one version of a script, or module, or function, on the same system. I pretty much read this as, always include the code necessary to ensure you’re working the correct code. It makes sense to me that everyone just simply get into this habit now.

We also got to look at the below three lines of code; it seems like I see them everywhere. They are a product of the New-Fixture Pester function. They are included in the .Tests. file created by this function; a function that produces a script file, and test file for the script file that includes a failing test. Remember, we write our tests first, ensure that each fails, and then start coding our solution, which in turn corrects our tests.

$here = Split-Path -Parent $MyInvocation.MyCommand.Path
$sut = (Split-Path -Leaf $MyInvocation.MyCommand.Path) -replace '\.Tests\.', '.'
. "$here\$sut"

While I didn’t find it in the book first — although, I did determine it is included — I stumbled across the meaning of $sut earlier yesterday. It stands for system under test. The next thing we covered was how to modify our tests files when working with modules. The code included in the book was substantially different from the code above. I’m certainly glad I don’t have to figure that one out myself — thanks, Adam.

The chapter continues on to discuss the Input/Execution/Output pattern — I can kind of seeing myself use this pattern. The best part after the chapter opening, however, was the discussions on Describe blocks, naming conventions, and tagging. It was nice to see the preferences of someone else. For me, I cannot seem to stop adding colons after the Name parameter values for the Describe, Context, and It blocks. They should just be there by default… to me, at least.

Describe -Name 'Advanced Function Template 2.3.4:' {
    Context -Name 'Tests without including parameters:' {
        It -Name 'Testing empty Advanced Function Template:' {
            ___-_________ | Should -Be $null
        } # End It.
    } # End Context.
} # End Describe.

Describing Advanced Function Template 2.3.4:

  Context Tests without including parameters:
    [+] Testing empty Advanced Function Template: 242ms

Off to the next chapter.