Pester Testing Styles

Pester is a great testing framework for Powershell. And it can be used in a variety of different testing styles: TDD, BDD, etc. I’m going to look at two different styles, both of which are perfectly good to use.

TDD’ish with BeforeAll / AfterAll

Lines 4 through 7 are used to ensure that module don’t get repeatable imported, when this tests are run as part of a Test Suite. However, they will allow modules to be reloaded if you are running the individual test file within VSCode. For the most part, they can be ignored.

In this more Test Driven Development style test

• The Describe blocks name is the function under test
• And each It test is labelled to describe a specific scenario it is going to test
• All the logic for setting up the test and executing the test are contained within the It block
• This relies on the Should tests to have clear enough error messages that when reading through the unit tests output you can intuit what was the failing condition

This is a very straight forward approach and it’s really easy to see how all the pieces are setup. It’s also very easy for someone new to the project to add a test to it, because everything is so isolated. One thing that can really help future maintainers of a project is to write much lengthier and more descriptive It block names than the ones in the example, in order to help clarify what is under test.

Some things to note:

In this setup, the BeforeAll script is used to configure the environment to be ready for tests that are about to be run. Over time, this function has been replaced with BeforeEach, but for this example I’m using BeforeAll. The BeforeAll is setting up some values that I want available when the test is run, or a variable I want available when the test is run. I put a prefix of $script: on the variable created within the BeforeAll function because I have seen behavior where the variable was no longer defined outside of the scope of BeforeAll.

The AfterAll is a corresponding block to the BeforeAll, and is pretty self explanatory. The interesting part of the these two blocks is that they have to be declared within the Describe block and not within the InModuleScope block. They will not be run if they are declared in the InModuleScope block.

BDD’ish with try / finally

Lines 10 and 11 are used to ensure that that module has been configured correctly (for normal usage … not specific to the tests) and ensuring that the module isn’t being reloaded when being run in a Test Suite.

In this more Behavior Driven Development style test

• Uses the Describe block to outline the preconditions for the tests
• Immediately following the declaration of the Describe block, it has the code which will setup the preconditions
• Uses the Context block to outline the specific scenario the user would be trying
• And, immediately following the declaration, it has the code which will execute that scenario
• Uses the It blocks to outline the specific condition that is being tested.
• This requires more code, but makes it clearer what condition actually failed when reviewing unit test output

This is not as straight forward of an approach, as different areas of the code create the conditions which are being tested. You might have to search around a bit to fully understand the test setup. It also adds a little more overhead when testing multiple conditions as you will be writing more It block statements. The upside of that extra work is that the unit test output is easier to understand.

Some things to note:

In this setup, variable scope is less of an issue because variables are defined at the highest scope needed to be available in all tests.

The BeforeAll/AfterAll blocks have also been replaced with try/finally blocks. This alternative approach is better supported by Pester, and it can also help new developers make a key insight into the way Pester tests are run: They are not run in parallel, but instead are run in order from top to bottom. Because of this, you can use some programming tricks to mock and redefine variables in particular sections of the code without having to worry about affecting the results of other tests.

Deleting cached metadata from local NuGet

The Issue

This article will help you resolve a nuget issue that involves packages which have case-sensitive misspellings in their dependency lists. Here is a sample error message:

Install-Package : Unable to resolve dependency 'Microsoft.Extensions.COnfiguration.Builder'

The Conditions

This is a very specific scenario. So, it takes a couple of preconditions to create:

• You have to have attempted installing the nuget package into a project.
  
• And, the installation had to fail with the above message. Here’s a screen shot for more context.
  
  
  
• The installation needs to leave your system with the metadata for the package downloaded, but the actual .nupkg is no where on disk.

The Solution

In this scenario, your package metadata cache (called the http-cache) has been updated with the packages dependency list. So, the next time you attempt to call nuget.exe; instead of fetching a fresh copy of the packages metadata from the source, it will use the cached version. To fix this, we’ll need to remove the cached metadata.

1. Find the package metadata store on your computer (reference docs):
   
   nuget locals all –list
   
   
   
2. Use the http-cache value provided, and open the folder in file explorer. And, then find the subfolder which matches the package source.
   
   
   
3. Within the subfolder, find the package you’re looking for and delete it.
   
   
   
4. Now, you are ready to reinstall the package from nuget using the latest metadata information.
   

RSAT Setup on Windows 10 1903 - 0x800f0954

Windows 10 1803 was the last time that Windows 10 had a separate RSAT download bundle. This the note from the download page:

IMPORTANT: Starting with Windows 10 October 2018 Update, RSAT is included as a set of "Features on Demand" in Windows 10 itself. See "Install Instructions" below for details, and "Additional Information" for recommendations and troubleshooting. RSAT lets IT admins manage Windows Server roles and features from a Windows 10 PC.

This is great! It makes re-installation of the RSAT tools just a little bit easier; and a little bit more aligned with automation.

A very nice Microsoft MVP, Martin Bengtsson, saw this new direction for installation and built out an easy to use installation script written in powershell. Here’s a blog post on what it does and how to use it.

The download of the script, execution and setup would have been pretty easy except for one thing … Error 0x800f0954.

It turns out that you need to enable a Group Policy that will allow your machine to download the optional RSAT packages from Windows Update servers instead of your on-premise Windows Server Update Services.

Luckily, Prajwai Desai has already figured this out and has an easy to follow set of instructions to update your Group Policy and allow for the download to occur.

Basic Install-WindowsTaskTemplate

I don’t install powershell scripts as Windows Tasks every day (any probably need to find a way for another system to manage that responsibility), so it’s easy to forget how to do them. Here’s a quick template to install a Windows Task on a remote machine:

Fun Little Cryptogram

There’s an interesting site https://ironscripter.us/ which creates powershell based scripting challenges for practicing DevOps thinking and continual learning. It’s kind of like a kata website with a funny “Battle for the Iron Throne” feel to it.

A few days ago they posted a really small cryptogram to find a hidden message within some text. I say really small because I have a coworker that is active in crypto games and the stuff he does is mind blowing (https://op011.com/).

Ironscripter’s challenge is more light hearted and just a quick game to help you think about powershell, string manipulation, visualizing data to make it useful and so on. So, here’s my solution to the challenge.

(I think I might go back later and use a language file to try and match the text in the possible solutions; instead of trying to look through them manually.)

(Thanks to David Carroll for pointing this site out: His solution)