I’ve written some Pester tests before for a couple of different modules that I have authored or helped author.
In those cases the tests seemed to come more naturally, “get a collection of objects. The collection should have this many records, and these properties” “Add a record to the collection. The collection should have one more record than before.”
I’ve just finished a fairly simple function that updates the “Location” property of printer objects via CIM. Because it has the potential to touch every printer object on a server, it has been suggested that I write a set of Pester tests for this function to help demonstrate that the function is ‘safe’ and ‘only does what I claim it does’.
It uses a couple of Get-CIMInstance calls, does a little string manipulation, and then does a set-CIMInstance to push the change.
I don’t really feel obligated to test whether Get-CimInstance works properly, though somehow, mocking the Set-CIMInstance seems somewhat disingenuous.
It seems like the key points are “Did I do the string manipulation correctly?”, and “Is the Location property the ONLY thing being changed?” The latter seems like the harder one to test. Sure, Set-CIMInstance’s Passthru switch gives us an object we can compare with our original, but that means we still have to make a change to a real printer object somewhere. Is there a way around that?
I’m still Google searching, and reading, so if I just haven’t found the right article yet, please don’t stomp on me too hard.