Unit Testing with PowerShell, Part I

I’ve been looking closely at Windows PowerShell, the new Microsoft shell and scripting language. The more I look, the better I like PowerShell. Because PowerShell can tap into the .NET Framework, you can write lightweight unit test automation with PowerShell. Let me show you what I mean in a series of short blog entries. If you want to use PowerShell to perform a unit test, that is, test a method or property of a class, you must be able to call the method or property. Suppose you have a classic example of a Point class implemented in C# like this:
namespace MyPointLib
  public class Point
    private int x;
    private int y;
    public Point(int x, int y)
      this.x = x; this.y = y;
    public int X
      get { return this.x; }
      set { this.x = value; }
    public int Y
      get { return this.y; }
      set { this.y = value; }
    public double Distance(Point P)
      return Math.Sqrt((Math.Pow(((double)(this.x – P.x)), 2)) +
            (Math.Pow(((double)(this.y – P.y)), 2)));
  } // class Point
} // ns MyPointLib
The rather ugly code in the Distance() method returns the geometric distance between two points. Notice that Distance() is an instance method so the first point object is implied with the "this" keyword. Let’s first look at how to call the Distance() method:
# callDistance.ps1
[Reflection.Assembly]::LoadFile(‘C:\MyLibs\MyPointLib.dll’) | out-null
$p1 = new-object MyPointLib.Point(3,0)
$p2 = new-object MyPointLib.Point(0,4)
[double] $dist = $p1.Distance($p2)
$s = "{0:f2}" -f $dist
write-output $s
# end script
I assume that my Point class is contained inside a MyPointLib.dll file. The first step is to load the .NET assembly containing the DLL by using the static LoadFile() method of the System.Reflection.Assmbly namespace. The LoadFile() method requires a fully qualified path. The pipe to "out-null" suppresses messages from LoadFile(). Next I use the new-object PowerShell cmdlet to instantiate two Point objects. Now I can call the Distance() method under test. Notice I use the ability of PowerShell to supply a .NET-based data type to the return value, but I could have left out the [double] qualifier if I wanted. I transfer my return value into a string formatted to two decimals. I finish by printing the formatted result, in this example 5.00, to the console.
This entry was posted in Software Test Automation. Bookmark the permalink.

2 Responses to Unit Testing with PowerShell, Part I

  1. T says:

    I\’m currently going through your book and I have one big question:  Why was the source code for the applications the tests are written for not included?  Albeit, it is good experience to write the little apps myself, but since my focus is on becoming an SDET I\’d like to have had the apps provided and then put my energies on learning to code the tests. 
    By the way – great book!  I was totally lost about how to write C# automation until I found it.  I\’ve already talked a couple other people into buying it 🙂

  2. James says:

    First, thank you for the kind words about ".NET Test Automation Recipes". The book has many of the techniques I had to learn the hard way when I was a tester at Microsoft. Now, you\’re right, I did not include the source code to all of the programs which were being tested (although I did include the key code for some of the applications under test). The main reason wass simply space. When I was asked by Apress Publishing to write the book, there were pretty solid guidelines on how long the book should be. Adding in the code for all the AUTs would have added a lot of pages and put me over my limit.

Comments are closed.