PowerShell for acceptance testing

PowerShell with its .NET integration and more and more products/platforms shipping with native PowerShell cmdlets is a great tool for automated testing. (I even posted a sample PowerPack helping organize tests in PowerGUI a few years ago.)

We at Quest Software are using PowerShell a lot for our software development and testing. Our SharePoint management team is on the cutting edge and extended acceptance testing Fitnesse framework to PowerShell.

But wait, now it gets really cool: they have open-sourced the PowerShell Fitnesse framework – PowerSlim at codeplex for everyone to download, use, modify, and update!

Read more about PowerSlim in Konstantin’s blog here.

TFS inside PowerGUI

Steve Crouse has recently published his PowerGUI pack for Microsoft Visual Studio Team Foundation Server – thus, fulfilling James Manning’s long time wish. 😉

This is a very nice tool allowing for browsing the work items for all the projects on a Team Foundation Server either by area or iteration. In addition you can view all open work items assigned to you, regardless of project. Project metadata such as the work item editing form definitions can be viewed for each project.

The default work item edit form can be launched for work items (although until PowerShell 2.0 is released with support for execution under Single-threaded Apartment mode the form does not function correctly.)

And, as usual the PowerShell code tab lets you easily see how everything you do translates into PowerShell – so you can later use this knowledge to automate things in your project (Steve basically loads the Team Explorer assemblies and uses them to connect to the server and retrieve data.)

You can download the VSTFS pack and leave your comments and feedback to Steve.

Tags: PowerGUI, PowerPack, PowerShell, TFS, software development, software testing
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

Counting lines of source code with PowerShell

How do you count the lines of code your application has? As far as I know Visual Studio does not provide this functionality, so needless to say, we are doing that with PowerShell 😉

$num = 0
dir c:\root\ -include *.cs -Recurse | ForEach-Object { 
	$file=[array](Get-Content $_ ) 
	$num += $file.length 
}
$num

You obviously need to change c:\root to your root folder path, and change the *.cs mask to the one applicable to your source code.

Tags: PowerShell, software, software development
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

Automated Software Testing with PowerShell and PowerGUI

PowerShell is great for automated software testing. We all know that and some of us even have some experience doing that. However, wouldn’t it be great to have a UI console to manage and run the individual test scripts?

Now you have one!

This PowerGUI-based console allows you to:

1. Run selected/all/based on criteria test scripts.
2. See results, last run time, modification time, error messages.
3. Filter and sort by any of the aforementioned properties.
4. Add new test scripts.
5. Edit test scripts.
6. Copy test scripts to serve as models for new scripts.
7. Delete scripts.
8. Produce reports.
9. Schedule tests for regular automated runs.

You can watch the automated software testing demo and download (absolutely free) the testing console at PowerGUI.org.

Enjoy and let me know if you have any feedback/feature requests!

Dmitry

Tags: PowerShell, QC, PowerGUI, PowerPack, Webcast, UI, software development, Demo, QA, software testing, software
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

PowerShell session at St. Petersburg .NET Usergroup – July 6th

Next Friday, July 6th 2007 I will be presenting at St. Petersburg (Russia) .NET Usergroup.

The usergroup will start at 6 pm local time and will go till approximately 9. We will start with Gaidar Magdanurov demoing some of his WCF work, and then I will do a PowerShell for developers session, sharing our experience and evangelizing PowerShell as the best command-line you can implement for your applications.

If you happen to be in St. Petersburg, Russia please register and drop by:

http://sp.ineta.ru/Events/EventInfo.aspx?ID=2b472d76-b54f-41dd-b753-4a793eba19ff

Tags: PowerShell, ineta, Conferences, Demo, software development, .NET, software

Autoupgrade for PowerShell snapins?

There’s an interesting side-effect of being agile and releasing updates too often – not everyone is able to keep track of your updates and upgrade to the latest version.

With rich applications this is kind of easier. For example, PowerGUI checks for newer version on start-up (we even have a bug when it manages to display the notification behind the splash screen) and offers to perform the upgrade.

By how would you handle the same issue in the command-line?

AD cmdlets 1.0.0 had issues installing on Vista/Longhorn. We fixed this in 1.0.1. The current version freely available for download is 1.0.3 and there are still people trying to use 1.0.0 and suffering from all the issues we have fixed a long time ago.

Is anyone trying to solve similar issues with other PowerShell snapins? Any advice?

One thing I find useful is making PowerShell at least display the snapin version so you know which computer has which version installed (yes, you can look this up in Add/Remove Programs but that’s not that handy.) For AD cmdlets you can do this by checking the version info with the following command:

(get-command (get-pssnapin Quest.ActiveRoles.ADManagement).ModuleName).FileVersionInfo.ProductVersion

Or even modify your profile to have that displayed at each startup:

# add the following code to your profile
# this gives the greeting message with the version info

"Loaded AD cmdlets v."+ (get-command (get-pssnapin Quest.ActiveRoles.ADManagement).ModuleName).FileVersionInfo.ProductVersion

# this changes the window caption:
function Prompt
{
$host.ui.RawUI.WindowTitle = "ActiveRoles Management Shell for Active Directory (beta) v."+ (gcm (get-pssnapin Quest.ActiveRoles.ADManagement).ModuleName).FileVersionInfo.ProductVersion
"PS> "
}

But this still does not give auto-update… Can you even have the snapins go to the internet, check for latest version, download it and start the upgrade?

Tags: AD cmdlets, PowerShell, software development

PowerGUI 1.0.6 released!

We have just made PowerGUI 1.0.6 available for download from http://PowerGUI.org.

As I mentioned before, stability was a priority for this release, so there are no radical changes apart from multiple bugfixes and minor improvements.

Setup should stop giving weird messages on Vista and Longhorn, filters work correctly even when 0 objects are displayed, PowerShell snapins don’t disappear and so on. You can read more information on the fixes 1.0.6 has on the PowerGUI Feature Roadmap page.

Also, because of the issues we had with the initial 1.0.5 setup, we are now taking a more staging approach: we put the new version on site couple of days ago and waited for some time before making the announcement in this blog. (As usual, Richard was the first to spot that and report in his blog! I wonder where he finds time for all that?)

No one reported any issues – so I am posting this. However, that’s not the last stage. We will leave it for a few more days in the manual update mode. Only if we get no complaints we will turn on autoupdate for 1.0.5 so all PowerGUI installations connected to the internet prompt user to perform the upgrade.

Tags: PowerGUI, QC, PowerShell, QA, software development

Too much xml formatting for PowerShell is a bad idea

PowerShell is extremely flexible and provides cmdlet developers (and PowerShell users) a lot of opportunities to adjust the behavior of the system. One of the ways is formatting display output.

Have you ever wondered how PowerShell decides which columns to display when you run Get-Process? It actually uses *Format.ps1xml files to look up the columns to display. The information in the files includes column titles, width, and the actual data to be used. Even more, you are not limited to using just the properties which the actual objects have – your column headers can be different from the property names or can even be calculated dynamically using scriptblocks.

This is extremely powerful and allows you to change the formatting for yourself without having to ask cmdlet developers to change the code. However, if you are a cmdlet developer please never use this flexibility because you might really confuse your users.

Here’s a quick example of how this confusion can happen (start your PowerShell prompt and try it yourself):

Let’s start by checking out the newest 10 Application log events:

PS C:\> get-eventlog -logname Application -newest 10

Index Time          Type Source                EventID Message----- ----          ---- ------                ------- -------

 1349 May 11 18:31  Info Windows Error Rep...     1001 Fault bucket 346834087, type 1...

 1348 May 11 18:31  Erro Application Error        1000 Faulting application agentsvr.exe, version 5.2.3790.1241, tim...

 1347 May 11 18:29  Info Windows Error Rep...     1001 Fault bucket 347717822, type 1...

 1346 May 11 18:29  Erro Application Error        1000 Faulting application agentsvr.exe, version 5.2.3790.1241, tim...

 1345 May 11 18:28  Info Windows Error Rep...     1001 Fault bucket 347717822, type 1...

 1344 May 11 18:28  Erro Application Error        1000 Faulting application agentsvr.exe, version 5.2.3790.1241, tim...

 1343 May 11 17:55  Info SceCli                   1704 Security policy in the Group policy objects has been applied ...

 1342 May 11 14:12  Info Outlook                    32 The store C:UsersdsotnikoMail2006.pst has detected a cata...

 1341 May 11 14:11  Info Outlook                    32 The store C:UsersdsotnikoMailTheArchive.pst has detected ...

 1340 May 11 14:11  Info Outlook                    32 The store C:UsersdsotnikoMailIDM.pst has detected a catal...

We get a nice well-formatted table. Everything is good. Well, until we start trying to use the columns of the table. For example, let’s try changing the set of columns so we only see EventID, Type, and Time:

PS C:\> get-eventlog -logname Application -newest 10 | Format-Table EventID, Type, Time

           EventID Type                                    Time           ------- ----                                    ----

              1001

              1000

              1001

              1000

              1001

              1000

              1704

                32

                32

                32

What happened? Why Type and Time columns are empty now? This is because such properties actually do not exist and are a result of formatting made in the xml files.

We cannot sort by Type either:

PS C:\> get-eventlog -logname Application -newest 10 | Sort-Object Type

Index Time          Type Source                EventID Message----- ----          ---- ------                ------- -------

 1343 May 11 17:55  Info SceCli                   1704 Security policy in the Group policy objects has been applied ...

 1344 May 11 18:28  Erro Application Error        1000 Faulting application agentsvr.exe, version 5.2.3790.1241, tim...

 1342 May 11 14:12  Info Outlook                    32 The store C:UsersdsotnikoMail2006.pst has detected a cata...

 1340 May 11 14:11  Info Outlook                    32 The store C:UsersdsotnikoMailIDM.pst has detected a catal...

 1341 May 11 14:11  Info Outlook                    32 The store C:UsersdsotnikoMailTheArchive.pst has detected ...

 1348 May 11 18:31  Erro Application Error        1000 Faulting application agentsvr.exe, version 5.2.3790.1241, tim...

 1349 May 11 18:31  Info Windows Error Rep...     1001 Fault bucket 346834087, type 1...

 1347 May 11 18:29  Info Windows Error Rep...     1001 Fault bucket 347717822, type 1...

 1345 May 11 18:28  Info Windows Error Rep...     1001 Fault bucket 347717822, type 1...

 1346 May 11 18:29  Erro Application Error        1000 Faulting application agentsvr.exe, version 5.2.3790.1241, tim...

Nor can we filter by Type:

PS C:\> get-eventlog -logname Application -newest 10 | where {$_.Type -eq Error}
You must provide a value expression on the right-hand side of the '-eq' operator.
At line:1 char:66
+ get-eventlog -logname Application -newest 10 | where {$_.Type -eq
PS C:\> get-eventlog -logname Application -newest 10 | where {$_.Type -eq Erro}
You must provide a value expression on the right-hand side of the '-eq' operator.
At line:1 char:66
+ get-eventlog -logname Application -newest 10 | where {$_.Type -eq

Of course the workaround is to use native properties instead and replace in the examples above Type with EntryType, and Time with TimeGenerated. The same workarounds work for PowerGUI (which is indeed affected and shows “pseudo-properties” just fine but fails to sort and filter by them). But if you are a cmdlet developer I beg you to not make your users search for those workarounds and keep your formatting simple: no scriptblocks and no titles mismatching property names.

And if you don’t believe me check-out Jeffrey’s blog post on how formatting really works.

Tags: cmdlets, PowerShell, software development

UI for Rapid PowerShell-based Software Testing

Another very important category of PowerShell and PowerGUI users are software testers (a.k.a. quality control engineers). With these two technologies QC guys can start doing their work long before they get the final UI from the development team.

PowerShell nicely separates application logic from user interface. PowerGUI provides for a way to construct a UI from PowerShell cmdlets by just picking and choosing the ones to use. Thus, QC guys can start testing parts of a product long before developers make product UI good enough. Testers can just take the PowerShell cmdlets dev releases, create their own light UIs with PowerGUI, and use PowerShell scripts to automate testing.

In a nutshell (oversimplifying and taking design, etc. out of the picture) software development process consists of developers writing the code and at some stage (often called RTQC – release to quality control) being able to start giving some bits and pieces to testers so they can start breaking it apart. The current trend is to try to make the process iterative so developers are able to give the product to QC more often in smaller chunks rather than spend months (years) developing and then giving the whole huge piece to QC.

The problem is that quite often doing such small iterations early is not that feasible because of the user interface being the bottleneck and lagging behind the business logic implementation. Turns out that the problem gets significantly mitigated once development starts using PowerShell to implement the application business logic.

Once any cmdlets become available testers can start constructing UIs from them with just few clicks and keyword search. And even better they can start taking the PowerShell code and using it to create UI-independent code to automated testing.

Microsoft Exchange team claims this non-UI testing helped them in their last release process. And it looks like the interest to using PowerShell to make software testing more efficient is gaining traction.