PowerShell, Tests and CI/D

Maybe you have an ASP.NET web site, and maybe you have a collection of PowerShell modules used for various automation tasks, like moving files between environments, kicking off batch processes, moving assets to the your CDN or similar things. If so these bits of PowerShell contain important bits of logic; if they don't work your site doesn't work properly.

Naturally you want to apply the same discipline to the PowerShell code as to any other production code, which includes TDD and Continuous Integration/Delivery/Deployment (CI/D). Furthermore I'll assume that you already have tests around your C# code, and that your CI/D setup runs these tests and reports the result.

In this situation you can TDD by writing test functions in the PowerShell modules themselves and call them from the command line. This, of course, becomes tiresome quickly as the number of tests rise, so you'll soon find yourself  writing ad hoc test runners for each PowerShell module. This works. Sort of. But it's still tiresome to run the tests selectively, and just as importantly, this doesn't fit into your CI/D setup which is geared towards your xUnit (or similar) test suites.

One quick and simple way to get around this issue is to write the tests in C# just as any other tests and simply call the PowerShell from there. Like so:



This isn't perfect:

• It's somewhat slow. 
• The call out to the PowerShell under test is tugged away inside a string.Format call
• The tests and the code under test are written in different languages, which doesn't sit well with me. It introduces an odd asymmetry and it creates an artificial barrier between the tests and the code under test.

The big win on the other hand is that it fits right into your existing TDD and CI/D setup.

Random Thoughts on Tiobe Index January 2011

The Tiobe index is an index of the popularity of programming languages (formally defined here).
According to the Tiobe web site "the index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system."

Some Data to Notice From the Index

As someone who has worked mainly in .NET through the last several years, my interest in the index focuses on .NET languages (and on my favorite language for recreational coding for some time now: Scala). The rankings of .NET languages in the January 2011 index are:

• F# ranked between 50 and 100 (the index put these 50 in one big pile because differences the in scores are minuscule)
• VB.NET at no. 49
• PowerShell at no. 28
• C# at no. 6

For perspective here are some selected other languages:

• BETA ranked between 50 and 100
• AWK at no. 31
• T-SQL at no. 17
• Ruby at no. 10
• VB at no. 7
• Python at no. 5

And also worth noticing is that Java, C and C++ take the top 3 spots, and have for a decade.

What I Get From That Data

Now what does this mean for a .NET developer?

1. C# is hugely popular, but still much, much less popular than Java. Looking at the long term trend C# is steadlily gaining ground. So having and maintaining C# skills is a really good idea in terms of making a living.
2. VB.NET is so unpopular it's almost off the charts...in a bad way. But (!) considering how the Tiobe index is done I don't think it distinguishes VB and VB.NET properly. So IMHO it's more fair to add the VB and VB.NET scores which would place VB.NET at 5th place - where VB is now. If this is true having VB.NET skills is a really good idea too, but the long term VB.NET trend is downwards, especially over the last couple of years. So maybe it's time to translate those VB.NET chops to C# chops?
3. F# doesn't seem to be going anywhere. So don't learn F# for job security. Learn it to open your mind. But then again, if you want to open up your mind, and you're a .NET dev, why not look outside .NET and do Scala or Clojure or Erlang or something completly left field?
4. PowerShell seems to be becoming important. Maybe it's time to really learn it.

 What does it mean for the .NET community?

1. Assuming the VB and VB.NET points needs to be added C# and VB.NET combined would weigh in at a 3rd place, meaning that .NET is doing very, very well in terms of popularity. 
2. Both Ruby and Python are doing very well. So if the Iron* languages are dropped an opportunity for engaging two very large communities is lost. That would be really sad!

Those were my 2 cents. Go check the index out, and make up your own mind. And let me know what you think :-)



Oh, and Scala is at place 50, just within the list proper. Still rooting for it :-)

Build automation with psake

I finally got a chance to take a proper look at psake, a build tool using PowerShell for the build scripts. Below is a psake script I did for a propject. It can compile the code by using MSBuild, clean up binaries, run NUnit tests, measure test coverage, and show the coverage results in the NCover gui. To do so a few paths are setup in the propoerties section, and it is assumed that tests reside in projects with names that end with Test:

properties {
 $base_dir = Resolve-Path .
 $testAssemblies = (Get-ChildItem "$base_dir" -Recurse -Include *Test.dll -Name | Select-String "bin")
 $buildartifacts_dir = (Get-ChildItem "$base_dir\src\" -Recurse -Include bin)
 $src_dir = "$base_dir\src"
 $tools_dir = "$base_dir\tools"
 $nunit_dir = "$tools_dir\NUnit-2.5.2.9222\bin\net-2.0"
 $ncover_dir = "$tools_dir\ncover"
 $db_script_dir = "$src_dir\Database"
 
 $env:Path += ";$ncover_dir;$nunit_dir"
 
 $test_result_file_postfix=".test-result.xml"
}

task default -depends Compile

task Compile {
 exec msbuild "$src_dir\DummyNameToProtectTheInnocent.sln"
}

task Test -depends Compile {
 foreach($test_asm_name in $testAssemblies) {
  $file_name =  [System.IO.Path]::GetFileName($test_asm_name.ToString())
  exec nunit-console.exe $test_asm_name /nodots
 }
}

task Coverage -depends Compile {
 $old_dir = pwd

 foreach($test_asm_name in $testAssemblies) {
  $file_name =  [System.IO.Path]::GetFileName($test_asm_name.ToString())
  $working_dir = [System.IO.Path]::GetDirectoryName($test_asm_name.ToString())
  $out_file_name = "$base_dir\$file_name".ToString().Replace(".dll", "") + ".coverage.xml"
  
  cd $working_dir
  NCover.Console.exe nunit-console.exe $file_name /nodots //x $out_file_name
  cd $old_dir
 } 
}

task Coverage_Gui -depends Coverage {
 foreach($xml in (Get-ChildItem . -Name -Include *.coverage.xml)) {
  tools\ncoverexplorer\NCoverExplorer.exe $xml
 }
}


task SetupDB {
 ."$base_dir\execute-sqlfile.ps1"

 Execute-SqlFile "$db_script_dir\RestoreBaseLineDB.sql" ".\SQLExpress" "master"
 Execute-SqlFile "$db_script_dir\SQL_CreateLoginAndPermissions.sql" ".\SQLExpress" "ConnectPortal"
 Execute-SqlFile "$db_script_dir\AddCompanyIDsToModul.sql" ".\SQLExpress" "ConnectPortal"
 Execute-SqlFile "$db_script_dir\UpdateOrder.sql" ".\SQLExpress" "ConnectPortal"
}

task Clean { 
 remove-item -force -recurse $buildartifacts_dir -ErrorAction SilentlyContinue 
}

I like the idea of using PowerShell for automation in projects targeting Windows for two reasons: One, its a real programming language (as opposed to xml), two, more and more things on Windows boxes can be set up and controlled through PowerShell. I want a real language for my build automation becuase it tends to become complicated over time, so sooner or later it I need the power of a programming language. And if the project only targets Windows, then PowerShell is good choice because its simply the Windows command line, and things like IIS, Exchange, SQL Server and so on provide PowerShell interfacfes.