James Crisp

Thanks everyone who came along last night. It was a fun session, with a lot of lively discussion, especially around project management and software design. As mentioned during the talk, you might want to check out nRake for .NET builds and psDeploy for Powershell deployments. Here are the slides from the talk. If you have any more questions or areas to discuss, please feel free to drop me a line.

I'll be giving a presentation at an Australian Computer Society Special Interest Group on Wed 2 June, 6:30pm. More details here.

The abstract is:

Application Lifecycle Management (ALM) covers the whole software development lifecycle and associated processes including project management, business analysis, testing, build and deploy and development. Based on experiences in the field on projects with ThoughtWorks and consulting with other teams, I will describe what I consider to be the ultimate ALM environment, using an agile approach and techniques. This talk will cover goals, assessment criteria, practices, tools, and physical workspace design.

Hope to see you there!

The inaugural Australian ALM Conference has been an interesting 2 days. The first day had a number of insightful talks, especially interesting to hear Sam Guckenheimer on how Microsoft has been reshaping their internal development practices into a more agile model. Today, I enjoyed Richard's agile adoption talk (hear hear!) and the other highlight was the last presentation of the day, explaining what's gone into the design of the new Windows 7 Mobile OS (though some things still seem under wraps). Also a pleasure to catch up with some old friends at the conference.

Conference organisation was very good (thanks to Anthony Borton and his team). The focus was very Microsoft centric, but next year, the plans are for a much wider variety of content. Lunar Park was a cosy conference venue and fun to go outside during the breaks and see kids screaming on rides and the sun shining on the bridge and harbour.

My presentation was 8.30am this morning (aargh!) but despite the early hour, there was a reasonable turn out and quite a few interested people asking questions. The plan was to co-present with Jason Yip, but he was called away to Perth so I presented solo. Unlike most other presentations at the conference, Visual Studio and TFS were barely mentioned. Instead I focused on current problems in each area of ALM, coming up with a criteria to assess this area, and what we usually do on projects to meet this criteria - eg, story walls, story maps, automated build and deploy etc. You can find the Powerpoint slides here. The slides are promises for a conversation (ie, mainly images with some notes), so don't hesitate to contact me if you want to chat.

Also, thanks Richard for this photo from the presentation:

Well, who doesn't write tests and do continuous integration (CI) these days? Whether you use one of the many Cruise Control variants, or Team City or some other tool, you most likely get a handy colour coding of builds as either green or red (ie, good, or bad). But, you can take this a step further!

Often on .NET projects, we have a little batch file that we run before checking in (often with a pause at the end so it can be run from a shortcut), to confirm that no tests are broken locally. Well, it's not much fun peering at the ugly Nant output (or whatever build system you use). Instead, it is quite easy to add a couple of lines to your batch file and change the colour of the console to bright Red or bright Green depending on the success of the local build. It is great for telling what the result was at a glance. I can't claim credit the idea - it was something we used at EDI for our custom build system, but here's some batch file code I whipped up which I can claim is all mine, every last GOTO of it! Enjoy

The following code uses NAnt, but you can replace it with MsBuild or any other build tool that returns a status code.

@echo off

color 07

tools\\nant\\NAnt.exe -buildfile:mybuild.build %*

IF ERRORLEVEL 1 goto RedBuild
IF ERRORLEVEL 0 goto GreenBuild

:RedBuild
color 4F
goto TheEnd

:GreenBuild
color 2F

:TheEnd
pause

NUnit tests can be run using a variety of different runners. Some common ones are:

• NUnit GUI
• Test Driven .NET
• Resharper test runner
• NUnit MS Build Task

The NUnit GUI and Test Driven create a new instance of the test class for each test run. This leads to more isolation but potentially slower performance.

Resharper and NUnit MSBuild Task re-use the same instance of the test class when running each test in the class. This can lead to unintended interaction between tests. Using these runners, it is vital to to assign initial values to instance variables in SetUp, rather than when they are defined or in the constructor.

If you use a mix of different test runners, you can end up with tests that pass on some machines and fail on others (eg, Test Driven locally works fine, but you use NUnit MSBuild Task on your build box and get intermittent failures).

If you have a ChildTestCase class that inherits from a ParentTestCase class, and both of these have a SetUp method, marked with the [SetUp] attribute, would you expect both to be called? If so, you would be sadly disappointed. Only the SetUp method of the ChildTestCase will be called, and the SetUp in the ParentTestCase will be ignored.

According to the NUnit documentation on the Set Up attribute, this is intended behaviour:

If you wish to add more SetUp functionality in a derived class you need to mark the method with the appropriate attribute and then call the base class method.

An alternative approach to get all your SetUps called is to have a base TestCase class define a protected virtual SetUp() (with the SetUp attribute), which all child classes override (and call base on their first line).