I use PowerShell to automate many things since the beginning of PowerShell in 2006. Since then the tooling has evolved a lot and the way I write scripts too. I used to prefer one big script and not split it up in many files and functions as long as possible. That was because source control integration was really bad and I had no good way to test isolated atomic functions. This has changed totally. With the PowerShell Tools for Visual Studio and Pester you can now really write high quality software with PowerShell. You can easily work with a source control system like GitHub or VSTS without leaving your IDE and you also can add continuous integration.

I’m trying to give you an End-To-End scenario that you can set up in less than an hour. Because this would be too long for one post I’m going to split it up in three parts:

PowerShell is used by admins, IT-Pros and developers. I try to make all the steps as clear as possible. If you’re a developer and familiar with Visual Studio and git you can skip certain parts. If you’re an IT-Pro and familiar with pester you can skip this parts. If you think some parts need more details, please leave a comment and I will add more content.

PowerShell Tools for Visual Studio

The PowerShell ISE is a great tool for writing PowerShell scripts. But it has some disadvantages:

• No source control integration
• No solution / project explorer
• No test runner

The advantages are, that it is x64 and has a native Shell integrated. But I prefer the comfort of an integrated environment. With the ISE I always had to jump between the ISE, explorer and a git prompt or Visual Studio.

If you install Visual Studio 2015 or 2015 Update 1 you get the option to install the PowerShell Tools for Visual Studio extension during installation. If you haven’t done it, you can easily install it from the “Extensions and Updates” window under Tools/Extensions and Update… in Visual Studio.

Remember that Visual Studio is still x86. So if you try to run scripts or tests from within Visual Studio you have to set the execution policy in a x86 shell. To do this go to C:\Windows\SysWOW64\WindowsPowerShell\v1.0 (this is where the x86 PowerShell resides) and launch powershell.exe as an administrator. Now set the execution policy to remote signed or unrestricted:

Set-ExecutionPolicy RemoteSigned

You don’t have to restart Visual Studio – this will take effect immediately.

Install Pester

You can download the latest Pester version from GitHub and copy it to a folder in $env:PSModulePath – but it’s more convenient to use a packaging solution like PSGet or Chocolatey.

Here is an example how you can install Chocolatey (in case you haven’t done it yet – line 1) and then install Pester (line 2).

iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))
choco install pester

Create a new repository on GitHub

You write a lot of scripts and don’t use a source control system because you’re an infrastructure guy? Start today and sign up for GitHub. With the current Visual Studio integration, it’s really easy to use and the advantages are really worth the initial effort.

If you have signed up for GitHub go to Visual Studio and connect to GitHub in Team Explorer under Manage Connections / Connect to GitHub.

If Visual Studio is connected to GitHub, you can create a new repository in Team Explorer under Connect / GitHub / Create. Just give it a name, pick a license and ignore file and hit create.

Create a Visual Studio Project and Solution

In Team Explorer under Home / Solutions click “New…” and select under Templates / Other Languages / PowerShell the “PowerShell Script Project”. I prefer to have my tests in a separate Project then the production code – so I create the test project first. The name for the project should be <you desired project name>.Tests.

In the Solution Explorer Delete the default script and add a test by right clicking the new project and selecting Add / New Item. In the dialog select “PowerShell Test”. Give the test a name that meets the Pester naming conventions (<your desired script name>.tests.ps1).

If you open now the Test Explorer (Test / Window / Test Explorer) your IDE should look like this:

If you run the test it is “skipped” because you have no assertions in the code. If your test does not run, you have probably not set up the execution policy correctly for x86 PowerShell.

I will explain in Part 2 the structure of the test and how it works. Right now we focus on setting up the projects. So just add the code to get a red test:

Describe "AnswerToUltimateQuestion" {

	Context "Exists" {

		It "Runs" {

			AnswerToUltimateQuestion | Should Be 42
		}
	}
}

If you run the test now it should fail.

Now add another project (leave out the .Tests for the project name) and rename the default script. Add the following code:

function AnswerToUltimateQuestion {

    [CmdletBinding()]
    [OutputType([int])]
    Param ()

    42
}

Modify the test and add the following three lines to the top of the file:

$project = (Split-Path -Parent $MyInvocation.MyCommand.Path).Replace(".Tests", "")
$sut = (Split-Path -Leaf $MyInvocation.MyCommand.Path).Replace(".tests.", ".")
. "$project\$sut"

The first line gets the path of the project by removing the “.Tests” from the path of the current test. The second line gets the corresponding script file by removing .tests from the name of test. The third line includes the script under test (sut) and makes available all the functions in that script.

If you have set up all names correct your test should now pass. Check my code on GitHub if you have problems.

Commit and Push/Sync your changes

Now that you have a working solution you want to commit you changes to your local repository and push them to the server.

In Visual Studio Team Explorer go to Changes. Add a comment and select “Commit and Sync”.

You have now a running PowerShell Solution with a Test Project on GitHub. In Part two I will show you how to Debug and Test your scripts from within Visual Studio.