Why Should I Test With PowerShell?

Why Should I Test With PowerShell?

  • Comments 13

Today, on our internal discussion list, someone asked if there were any advantages to testing with PowerShell versus testing with C#.

I was able to come up with 10 quick reasons to test with PowerShell:

  1. Being able to run command line programs easier within PowerShell
  2. Dynamically generating code or test data for a test case (fuzzing or data-driven testing get a lot easier with this)
  3. Being able to access COM easier within PowerShell
  4. Being able to embed PowerShell in C# (so you can avoid writing a framework and just embed PowerShell in your infrastructure)
  5. Being able to use weakly typed variables within PowerShell
  6. Being able to test APIs on the command line, so you test manually and then automate
  7. Getting a history of commands, to take what you've explored and turn it into a test case
  8. Being able to strongly cast or coerce types when needed
  9. Support for verbose, warning, and debug streams to provide additional test information
  10. Being able to use PowerShell's systems administration features to help  setup or cleanup a test environment

I hope these reasons help convince other software testers to use PowerShell. It can really make testing a lot simpler.

Hope this helps,

James Brundage [MSFT]

Leave a Comment
  • Please add 5 and 5 and type the answer here:
  • Post
  • Can you please tell me the name of for internal discussion group on which this was discussed? I wish to join it.



  • FWIW I wrote our software products regression test suite in PowerShell for many of the same reasons you list above.  Primary among those being the ease of invoking command line operations and monitoring stdout/stderr.  We also need to do a fair amount of test setup work involving munging files with regexes.  Powershell makes this a snap.

  • Could you please have some examples on each of these points, so that it would be helpful to all developers.

  • I wrote this comment on the suggestions thread but I'll copy it here too. This is a real difficulty with testing in PowerShell:

    Creating a new object from an assembly in a certain folder (C:\Users\Eric\someassm.dll) fails if there are dependent assemblies in that same folder (C:\Users\Eric\dependassm.dll) UNLESS you specifically include those assemblies too. I know this is due to Code Access Security in .NET but it really takes away a potential use of PS: quickly testing objects you just created in Visual Studio. Right now I have to rebuild simple command line programs in order to manually test a rebuilt assembly. It'd be much easier to just open a new PS window, load the main assembly and work with the new object there.

  • More information here on this subject would really be useful.  Currently, many groups use C# for test automation. I think one important reason for using Powershell to test with is the "virtuous cycle". A scripting language links administrators with test engineers. Often these two groups share a greater subset of skills with each other than developers. Writing test suites in C# often creates a full time job for a developer in test.  Creating the test suite in Powershell means that every Windows Server 2008 and Windows 7 administrator can eventually learn test engineering skills and Windows APIs without dealing with the C family of languages. Additionally, this adds API troubleshooting to "field workers" (e.g. network administrators, IT personal) who are going to be less likely to learn Windbg and C++ than you might imagine.

  • Real life applications have long namespace and class names. They pollute PowerShell code too much. Interactive typing is hard, in fact one has to type a lot if a method being tested on the fly accepts objects that have to be created by new-object with long type name + their parameters as well. Honestly, PowerShell *can* be used for interactive testing, but in reality it is not yet well designed for this.

  • You can shorten class names with a number of tricks in PowerShell.

    #1. You can always omit SYSTEM namespace when specifying a type

    #2. You can use -as [type] on a string to get a type, e.g.

    $sma = "Management.Automation"

    "$sma.PSObject" -as [type]

    #3. The same sort of trick applies to New-Object

    #4.  You can take a method on an existing object and see its overloads by omitting parenthesis, e.g.


    #5.  You can get method information on constructors in a readable form with PowerShell, e.g.

    [string].GetConstructors() | % { "$_" }

    Hope this Helps,

    James Brundage [MSFT]

  • These are very nice tricks, for testing or not, thank you. But this is getting too smart, not natural and obfuscating, too.

    For testing or not, it would be useful to have some native PowerShell accelerators like "using" directives or user defined namespace and type aliases, etc. Due to lack of this now "glide path" from C# to PowerShell is not that glide. C# code normally is a bunch of "using" directives and then types are used just by names. Often there are no full type names in C#, so that there is nothing to "just copy\paste". The funny thing is that sometimes for a type in C# code you do not even know (or remember) what namespace it belongs to. If you have just C# source being "converted" into PowerShell and no .NET development tools at hand (e.g. just a handy MSDN example and Notepad or ISE) then this task may be tough even for some programmers.

  • I'm not sure I would want to use PowerShell for low-level unit testing of managed code.  I'd rather use NUnit or mstest.  However for functional & regression testing of our applicaiton which involves firing off the app EXE with various input files, collecting and evaluating the outputs (both files and stderr), I think PowerShell is a great way to go.

  • >>"embed PowerShell in C#"

    Does anybody point me to some sample for this.

    If I understand right, I can develop custom cmdlets that implement some setting of my framwork. Then I use such cmdlets to pipline them the way my application logic requires it, and the users can use the same thing to script on their own.

    This way I kill the 2 flies in one shot - I develop applicaton logic and make application automation-ready automatically.

    Is all that true ?

  • majkinetor - this might overlap with what you're after (make application automation-ready automatically): PowerShellTunnel (http://code.msdn.microsoft.com/PowerShellTunnel).  For general embedding of PowerShell in C# I think look for the details of PowerShell's Runspace.

    Another reason why testing with powerShell is great:

    It's all just Text!  Given some helper functions then you have easy ad-hoc testing.  It's all text so just copy-paste into your 'reproduction steps' in your change tracking system...

  • Thanks Mat.

    Tunnel looks very intersting.

    ZOMG! I just started with PS before few days ago and I already have tones of things already here from Web applications to GUI apps over tunnels and ....

    I never thought I will say congratz to MS.

    And, yes, nothing compares to pure text (especialy no compiling).

  • Re: PowerShell "Using" statement ... in v2 you can just add type accelerators:


Page 1 of 1 (13 items)