Project Description

NUnit4PowerShell has been done to test PowerShell scripts with the NUnit framework.

Fixtures are written in PowerShell and this dll will read and execute them.

The goal is to automatically execute unit tests, for instance with a Hudson job, and look for scripts regressions.

NUnit4PowerShell is a library to execute tests written in PowerShell with NUnit.
The main advantage is to use the test function coverage of NUnit and to be able to execute them from PowerShell.

Purpose of this library ?

Unit testing, definitely.

Why did I do this library?

When I started to code this, my concerns were to test my scripts to prevent from regressions (a very common unit tests purpose). All my scripts were using some common functions library and I didn't want to test manually each scripts after each change.

To do so, I defined my target to be able to make "an Hudson job which will launch automaticaly tests after a commit and report failed tests"
I had a look on the good PSUnit (psunit.codeplex.com) which was not really covering my needs (I wanted a report at the end of the test).
Then I decided to write a library based on NUnit (Hudson job can publish a report after NUnit tests).

How does it work

NUnit4PowerShell dll looks for fixtures in a folder specified in NUnit4PowerShell.config file.
NUnit4PowerShell.dll will load PowerShell fixtures and execute them.

This library executes tests like NUnit. They are written in a PowerShell fixture and you can define a FixtureSetUp, a SetUp, a TearDown and a FixtureTearDown.
If you're not aware with NUnit process please take a look here : http://nunit.org/index.php?p=quickStart&r=2.5.9

What is a PowerShell Fixture file ?

A PowerShell fixture file is a PowerShell module (.psm1) : which means that it's not a executable script : it only contains functions
  • It's a file named with a specific pattern (for instance: PSFixture-*.psm1)
  • It contains several methods
    • a Fixture SetUp (optional) named SetUp-TestFixture
    • a SetUp (optional) named Set-Up-Test
    • at least 1 Test, following a name pattern (as Test-Function.*)
    • a TearDown (optional) named TearDown-Test
    • a Fixture TearDown (optional) named TearDown-TestFixture

What does a NUnit4PowerShell test looks like ?

Function are written in a PowerShell fixture files
function Test-Function.0.1Module_Exists_At_Path
{
[NUnit.Framework.Assert]::DoesNotThrow(
{ ((Resolve-Path $MODULE_PATH) ) } ,
"The module has not been found at the path '$MODULE_PATH' ")
}
  • You can notice the name of the function which has to be based on the test function name pattern filled in the NUnit4PowerShell configuration file (here Test-Function-*)
  • Function uses the NUnit.Framework, you have to load the dll inside each PSFixture
    • With [void][Reflection.Assembly]::LoadFrom("./NUnit4PowerShell/nunit.framework.dll")
    • Each test has to contain an assertion from the NUnit library

Limits

  • You have to load NUnit dll on the fixture
  • And use NUnit .NET object functions (which is an advantage from my point of view but less easy than cmdlet) :
  • To execute more than a fixture, you have to execute a command line : this limit is due to NUnit Suite limit which doesn't support the Suite execution easily: http://nunit.org/index.php?p=suite&r=2.5.9
  • If you double click on the NUnit4PowerShell.dll, the first fixture file of the folder will be executed
  • It's sometime hard to understand exceptions or fixture execution failure : to help on this concerns I add some logs (NUnit4PowerShell.log), not based on any logger framework (due to interference with PowerShell scripts using log4net)
  • To be able to debug a PSFixture, the Execute-NUnit4PowerShellTests.ps1script is available in the script folder. It reproduces the dll behavior
  • The C# runspace where the PowerShell is executed doesn't support some (very basics) cmdlet like Write-Host (and I guess all of these which interact with the console). To escape that a mock file exists in the project inside NUnit4PowerShell/Script folder and the file is named Mock-Cmdlet.psm1.
    • It overwrite the Write-Host cmdlet. If you meet other issues with based cmdlet, you just need to add them in this module.
    • This module is called at each runspace creation

Let me know if you meet some problems, I will be very pleased to answer you :-)




Last edited Feb 14, 2011 at 1:45 AM by maxence_modelin, version 17