As you advance in the Code-Run-Debug cycle of a new script towards completion it becomes more of an Correct-Test-Debug cycle. The emphasis clearly shifts from writing new code to testing and correcting existing code.
To make that easier we introduced a new ribbon tab with command specifically meant for testing. It contains a collection of already existing functionality plus some new features you may find helpful.
Note that some of these are PowerShell specific, such as ‘Script Analyzer’ and ‘Pester’, while others work just as well for VBScript and JScript.
The new Test tab has 6 panels: Check, Windows Sandbox, Build, Run, Debug, Arguments
Let’s go through them one by one.
The Check panel had four functions, three of which have existed before and are just resurfaced here with a more prominent placement.
– Script Analyzer will run the Script Analyzer module installed on your machine. If you don’t have it, get it here: https://github.com/PowerShell/PSScriptAnalyzer
– Pester will execute the Pester tests you have coded for your script. You need to install Pester of course. If you do not have that yet, we highly recommend to get it here: https://github.com/pester/Pester
– Performance graph logs CPU percentage and memory utilization of your script over time.
Subsequent runs with the same script allow you gauge the differences your changes made. Comparing the results from the last three times your script ran will help you determine if your changes made things faster and more efficient or not.
– Last but not least, and that is a new functionality, we have a function coverage profiler, which simply counts and logs how often each function or script script block gets called during a test.
When writing a script we often ‘re-use’ code from another script or something we found online by copying and pasting. Like it or not, that can leads to dead code, meaning functions which never get called.
Even if you dot source some files in PowerShell with frequently used functions, you may find that some files are included for no reason because no code in them ever gets called.
Last but not least, when testing you need to make sure that all parts of your get get exercised. The function coverage profiler will indicate any functions you did not call in your test, enabling you to adjust your tests to include all code. Specially when testing GUI applications it is not uncommon to miss certain events or
buttons and thereby not testing the associated event handlers.
2. Windows Sandbox
Windows 10 build 1903 introduced a new feature called Sandbox. https://techcommunity.microsoft.com/t5/Windows-Kernel-Internals/Windows-Sandbox/ba-p/301849
Windows Sandbox is not enabled by default, you must add this Windows feature manually. I have also noticed that it may fail to start after a larger Windows Update. It usually
helps to disable and re-enable the feature (requiring two reboots). So there are some growing pains as with any new substantial Windows feature.
It is however a great way to test an unknown script in isolation as well as making sure your script, packaged executable and/or installer operates in a brand new and pristine Windows installation.
This feature is sufficiently new and complex to deserve its own blog post. Using it is pretty straightforward, so go ahead. We will soon publish another blog post which focus entirely on testing with Windows Sandbox.
If you are using PrimalScript’s Script Packager or MSI builder, these command will allow you to re-build your EXE and or MSI from the Test tab without having to toggle to and from the Deploy tab
Running your script, packaged executable and installer is of course at the heart of testing, so the functionality from PrimalScript’s Home tab on its ribbon has a copy here. The additional Windows PowerShell and PowerShell Core commands enable you to quickly weed out any problems you might encounter in a new console.
Running your script isn’t always enough. During testing you will sometimes discover one or the other puzzling behavior you are not able to pinpoint without a closer look. That is why PrimalScript’s debugger commands also have a copy on the Test tab. They operate just the same way as on the Home tab.
Many command line scripts must accept a variety of arguments. It is essential to test a scripts behavior when invalid input is provided and of course you need to cover all different combinations of command line parameters while testing. To make that easier we added a field to enter you arguments on the ribbon. It does keep a history (20 items) to make it simpler to re-test previous arguments. A simple on-off switch turns arguments on and off. Arguments specified here are passed to any script or packaged script you are running or debugging here.
We actually liked this way of handling script arguments so much that we placed a copy of this panel on the Home tab.