Anyway, during my downtime I read a great article by Alistair Cockburn on “Are iterations hazardous to your project?” And yet again Alistair is spot on.  There are many nuggets in this paper but by far the one that rings home for me is the age old problem of clients not having the time to accept iteration deliverables.  With no feedback, where’s the value.  Agile development is about delivering value.  If you are not doing that, you are doing iterative development NOT agile development.

Another funny thing Alistair alludes to is are the macho agilists.  I’ve come across a number of these and I had to laugh out loud on the issue of iteration length.  Alistair is spot on with macho agilists opting for very short iteration cycles.  Don’t get me wrong, sometimes very short iterations are the right thing to do in certain contexts, but in others i’ve seen them used to by macho boys to demonstrate experience and knowledge over an unworthy (read as less experienced) agile opponents (read as team members) .   

Anyway, I recommend taking 10 minutes out of your day to read this article…

So I refreshed my memory with Groovy by reading the following:

• All the documentation at the groovy web site

Now, ready to flex my Groovy muscles I downloaded and installed:

•  The Eclipse groovy plugin. 

Then with that installed I ran through numerous examples.  But before you do anything, I think you simply have to read about Closures.  To my mind, one of the most powerful and well implemented features within Groovy. 

So I’m up and away with Groovy, then next logical step is to see how easy it is to integrate with some legacy Java applications that I have wandering around.  Also, just how easy is it to debug in and is the Eclipse plugin up to it. 

Not bad. Not bad at all. For the .NET guys, bear with the Java looking GUI and look to its ability to quickly and easily test web services.

Neat.

I am still coming down on the side of Scrum with a bit of XP, as opposed to XP with a bit of Scrum. The simplicity of Scrum, its clear and concise rules and practices, fit with the way I tend to run projects. I don’t know enough of about XP in practice, so I’ve decided to attend XPDay this November. Also, we just had the pleasure of Rachel Davies, the now chair of Software Practice Advancement 2007 (formerly OT) come out to our offices to run a number of XP sessions. Interesting stuff…

I left because the team structure had evolved into something that I couldn’t work within. I loved the people, but when things are better without you, than with, you walk away. In the beginning, as the team grew I mentored and coached, held frequent team meetings to synchronise knowledge and status, we delivered frequently (despite clearcase) and were quite proud of our continuous integration build environment. The business defined value. We delivered it. The team structure was flat. Work was fun.

Then the business threw more work at us. Management reacted by adding more levels of management (sigh!). The team moved from a flat to a hierarchical structure. The once fluid communication with the customer stopped. There was a layer between us and them. My project manager hat was removed. I was purely technical architecture now (”thank’s very much cleve, we’ll take it from here…”). The team stopped having meetings. The team became individuals. The individuals reported individually to the new project manager. The team became dysfunctional in some respects but we had to continue to deliver software. That’s what we do. We just did it in a different way.

During this change in team structure, I fought to maintain the close collaboration we had built up with the customer. I fought to protect the team dynamic. I failed. The islands of developers (read as component groups) were formed.

Currently, I’m half way through a book by Ken Schwaber called Agile Project Management with Scrum. It is the book that I wish I had known about to give to my project management to read, to understand what I was fighting for and why it was so important to both the business and development teams. I basically failed to articulate the guidelines, practices and rules of Scrum in a way that made sense to both of us.

Ken, I take my hat off to you. The more I read about Scrum, its case studies and how ScrumMasters have applied it to the thousands of projects out there, the better I feel. I always thought it was mad to fight complexity (software) with complexity (high ceremony process and/or methodologies). Although outwardly Scrum appears simple (this is good a thing), its conceptual rivers run deep. I am looking forward to learning how deep…

The first step is understanding how a java based FitNesse wiki ran my .NET acceptance suites.  Fortunately this was pretty easy.  Under the fitnesse install directory their is a subdirectory called dotnet.  It the dotnet directory there is a .NET implementation of the FitServer that consumes test tables and communicates back results.  All we have to do in our wiki pages to tell FitNesse to use the .NET FitServer instead of the Java one to run our acception tests.  This is done by placing the following at the top of the wiki page that you write the acceptance test in:

!define COMMAND_PATTERN {%m %p}
!define TEST_RUNNER {dotnet\FitServer.exe}
!define PATH_SEPARATOR {;}
!path dotnet\*.dll

That’s it.  Then add the following test table to your page as well

!|eg.ArithmeticColumnFixture|
|x|y|plus()|
|10 |2 |12 |
|12 |3 |15 |
|100 |4 |104 |

The syntax is simple enough. 

• Line 1:  The test fixture to run, with eg.ArithmeticColumnFixture being a fully qualified class name 
• Line 2:  These are public members on the test fixture in first two columns, and the final column is the method that is called to perform the test.
• Line 3-5: These values are assigned to the test fixture members and  the plus() called.

This page shows an example test table as it is rendered within the FitNesse.  Notice how FitNesse displays the .NET settings of the page.

To run the test, click the Test button that is in top left hand corner of the menu items.  (Note that to make a page a Test, select properties from the menu items and choose the Test option box.)

After you run the test, the results are displayed.

This works okay, now how do you write you own.  Take the following steps:

• Open your VS Studio Project with the code that you want to test.
• Write your acceptance test fixture code
• Have your project *.dlls copied into the FitNesse/dotnet directory (Post Build Events in VStudio are good for this).
• Write you test table wiki page and run.

One thing to note.  I was build using VS Studio 2005 and FitNesse was having problems finding classes within my assembly files.  To fix this I had to checkout the latest FitNesse.DotNet from the trunk and build it (You need NAnt). 

• svn co https://svn.sourceforge.net/svnroot/fitnessedotnet/trunk fitnessedotnet

Once done, I copied the required binaries into the FitNesse\dotnet directory and everything worked fine.

FIT is a Framework for Integrated Tests that was created by Ward Cunningham and is gaining popularity. FIT simply consumes test tables, where a test table is a bunch of acceptance tests with input values and expected results. The trick is to provide test tables in tools that customers use as part of the every day life, and what is more everyday than Word and/or the Web.

Focusing on the Web side of things, FitNesse is a software testing tool that front ends FIT with a wiki. In Fitnesse the customer can write acceptance tests as simple tables that can be executed. These executable test tables call the software that you wish to be accepted by the customer.

Installing Fitnesse

Hmmm. This wasn’t so hard, simply do the following:

• Download the latest zip and unpack into a directory of your choice.

At the time of writing, the latest zip was fitnesse20060719.zip. Note that FitNesse is a wiki implemented in java. However, it does support the running of acceptance tests for .NET. Now once unpacked, step into the root directory and issue the following:

• run -p 8888

This will display a little text to say all is well. Now traverse to the FitNesse wiki at:

• http://localhost:8888/

Here are a couple of quick links you should try:

• http://localhost:8888/FitNesse [ lists all pages within the wiki ]
• http://localhost:8888/FitNesse.DotNet [ the .NET page ]
• http://localhost:8888/FitNesse.DotNet.SuiteAcceptanceTests

The last one is very interesting because in the left hand menu, you’ll see the top menu item is Suite. Click this to run all the .NET acceptance tests. Note, that you need .NET installed on your Windows machine.

I’m tired. Tomorrow I’ll step through the problems I had trying to get my own acceptance tests running against inside Fitnesse.

1. TestDriven.NET that is suppose to provide good test integration with VS.NET.
2. Visual Studio Team Suite (VSTS) built in test framework. See what Charlie Poole, a member of NUnit team has to say about this.

So I installed NUnit and took the following steps within VisualStudio:

1. Created a new VS Solution with a C# Library project called basics.
2. Right clicked on the basics project and set the startup external program to be NUNIT_HOME/bin/nunit-gui.exe

Once done, everytime I run in debug it fires up the nunit gui and I can select my test and run it. I am now in a position to test and debug anything within the .NET platform that I can condense down into a simple test. Nice!

Again, that wasn’t so bad…