In my last blog entry I described how you can create a custom PowerShell script template and then make the template available from within Visual Studio as a New Item entry. This could be useful when you want to perform some lightweight PowerShell based test automation to supplement your other testing activities. By writing PowerShell scripts from within Visual Studio you get the advantages of general file management and integrated .NET help. However, when you are finished with your script, in order to run your test script you'll still need to leave the Visual Studio environment, launch an instance of PowerShell, navigate to your script and execute it. But there's a surprising alternative. CodePlex (the Microsoft-sponsored open source effort) has a neat Visual Studio add-on that places a PowerShell host directly inside Visual Studio. The screenshot below shows what I mean. Notice there is a VSCmdShell window at the bottom of Visual Studio, and I executed my custom PowerShell script from the host. Pretty neat. With the combination of a custom PowerShell template plus the VSCmdShell Visual Studio add-on, you can, in theory, completely write and execute PowerShell test scripts in the same environment as you develop your application under test. Currently, the VSCmdShell add-on from CodePlex is a bit on the rough side and, based on my experience at least, not quite ready for serious production use. However you can try it out and decide for yourself. Let me point out that the VSCmdShell add-on is a custom PowerShell host and is not the refined command shell host you get when you install PowerShell. For example, the VSCmdShell host supports the write-output cmdlet but does not support the more flexible write-host cmdlet. Also, the VSCmdShell does not read any of the $profile startup files. And so on. I intend to keep a close eye on the VSCmdShell project and I hope the volunteer developers take the rough edges off this interesting tool.

 

 

There are several interesting ways you can integrate Windows PowerShell and Visual Studio. Why would you want to do this? Consider the following scenario: you are using Visual Studio to create a C# project of some sort (a Windows application, a Web application, a Class Library, etc.) You wish to use some very lightweight PowerShell based test automation to supplement your unit tests and your medium weight C# test harnesses. In some situations you might want some sort of PowerShell - Visual Studio integration rather than using each separately. One neat trick is to create a custom Visual Studio Item Type as a PowerShell test script template so that inside Visual Studio you can right click on your Project name and select Add | New Item from the context menu and have your custom PowerShell template available. The process is quite easy in Visual Studio 2005 and 2008. First, create an empty .zip folder named PowerShellScript.zip on your Desktop. Next use notepad to create your custom PowerShell template. For example:

 

# PowerShell test automation template
write-output "Begin tests"

write-output "End test run"

 

Save this file as PowerShellScript.ps1 on your Desktop. Now use notepad to create this XML meta file:

 

<VSTemplate Version="2.0.0" Type="Item"
xmlns="http://schemas.microsoft.com/developer/vstemplate/2005">
  <TemplateData>
    <Name>My PowerShell Template</Name>
    <Description>My Custom PowerShell File</Description>
    <Icon>Book.ico</Icon>
    <ProjectType>CSharp</ProjectType>
    <DefaultName>PowerShellScript.ps1</DefaultName>
  </TemplateData>
  <TemplateContent>
    <ProjectItem>PowerShellScript.ps1</ProjectItem>
  </TemplateContent>
</VSTemplate>

 

Save as PowerShellScript.vstemplate on your Desktop. You should be able to figure out most of this XML file. Notice the Book.ico icon reference. This entry is optional. I hate creating .ico files so I just used one I found. Now copy files PowerShellScript.ps1 and PowerShellScript.vstemplate (and an icon file if you decide to use one) into the PowerShellScript.zip directory on your Desktop. Now copy the entire .zip folder into the language-appropriate Visual Studio user-defined template directory. On my Vista machine this is at C:\Users\myname\Documents\Visual Studio 2008\Templates\ItemTemplates\Visual C#. You can find the exact location on your particular machine from Visual Studio by Tools | Options | Projects and Solutions | General. Now, the next time you create any kind of C# project, you'll have your PowerShell template available as a New Item entry. Very cool. At this point you can write the PowerShell script within the Visual Studio environment where you get the advantages of general file management and integrated .NET help. Now to execute your tests you'd have to launch an instance of PowerShell, navigate to your script and execute it. In my next blog entry I'll describe an interesting alternative to this last step of the process.

 

Every now and then I'll hear people argue either that software testers absolutely must know how to code, or that software testers absolutely do not need to know how to code. I believe the true fact of the matter is that it totally depends upon the situation. At Microsoft for example, virtually all testers must have some knowledge of coding. Microsoft produces all kinds of software including complex systems software. Testers must know how to code so that can understand and effectively test the systems software they're working on as well as understand, modify, and write test automation which is the only practical way to test certain aspects of some types of systems software. On the other extreme you have pure manual testers who are testing a relatively simple (compared to systems software that is) application program of some sort. Do these kind of testers need to know how to code? Well, it depends. However, I can state this with pretty much 100% confidence: the more any tester knows about coding, they better he'll be able to do his job, and the more career opportunities he'll have. But here's an opinion I have that many of my colleagues (whose opinions I respect a lot) do not agree with. I believe that, in general, knowledge of specific programming languages is (in a way that I'll explain in a moment) actually more important for software testers than it is for software developers. My logic is that it is critically important for software developers to understand algorithms and problem solving. Sure, the programming language used is extremely important so that any algorithm can be implemented accurately and efficiently, but the underlying algorithms are in most (but certainly not all) cases more important than the choice of programming language used. Software testing is primarily an analysis activity so in many (but not all) situations software testers need to be able to understand the algorithms used in the software system they're testing, but not necessarily create very complex algorithms themselves. By sort of a weird default this means that knowledge of different programming language features is more important for testers, so that can quickly implement test automation (and test cases) that test the software system they're working on as thoroughly as possible. Now I'm not saying that this algorithms vs. languages importance idea is a Boolean thing; I'm merely suggesting that all software testers can do their jobs better and expand their career opportunities by learning how to program better and by learning multiple programming languages.