FitNesse revisited

I recently wrote about FitNesse saying that our goal was to allow domain experts to get on with testing while the developers could concentrate on building new features.

Wrong. Wrong. Wrong.

What I should have said was that the key to acceptance testing with FitNesse is collaboration. Testers and developers should work together when writing tests and developing features. This is what FitNesse makes possible.

Testing will always come at a cost. The trick is to make sure the returns exceed this cost. Junit has made this possible for unit testing.

When it comes to acceptance testing, the cost-benefit relationship is not so clear. FitNesse can swing the balance in favour of automation. So here's my revised list of tips for how to do this:

1. Collaborate when creating acceptance tests. Developers and testers should be encouraged to work together.
2. Create separate FitNesse fixtures for setting up test data, exercising the SUT, and making assertions on the result.
3. Names are important. The readability of your test cases will improve.
4. Write unit tests for your fixtures. Their design will benefit.
5. Keep your tests independent. Intra test dependencies will lead to tears.
6. Use dependency injection. Decoupled fixtures can be reused more easily.
7. Document your fixtures. This will help you write clear test cases.
8. Think carefully about logging. Debugging will be less painful.

Pythagoras moment

Monday evening was spent discussing retrospectives with fellow members of the Swedish Scrum User Group. I came away from the evening with a few new ideas but it wasn't until a couple of days later that I had a pythagoras-in-the-bath moment.

But first more about Monday. Once again we used the Open Space format for this get together. As Harrison Owen puts it:

Open Space Technology is effective when real learning, innovation, and departure from the norm are required. When you aren't quite sure where you are, and less than clear about where you are headed, and require the best thinking and support from all those who wish to be involved, Open Space Technology will provide the means.

Hold your horses! Isn't that also a perfect description of a retro. A bunch of enthusiasts getting together to come up with imaginative solutions to tricky problems. Why use open space just to discuss retros when open space can be used to do a retro? Eureka! Now I know how I'm going to do our next retro.

Retrospective serendipity

If we hadn’t run out of time at our latest retrospective then I wouldn’t have discovered SurveyMonkey.com.

We usually end our retros by dot voting on a list of suggested improvements. This time the retro had been particularly fruitful – lots of interesting discussions and a dozen improvement suggestions. And then our time ran out.

With various team members already heading off to their next meetings I rashly promised to send out an internet based survey so that we could at least prioritize our improvements list before the afternoon’s planning session.

And then I started to wonder if I’d promised too much. With no time to do an in depth market analysis and after a quick google I selected SurveyMonkey. A choice I wasn't going to regret. 15 minutes later the survey was sent out and in the following planning meeting we had a nicely prioritized list of suggested improvements.

It worked so well that I think we’ll do it this way again – even if we don’t run out of time in our retrospective.

Scrumming for Britain

As a scrum master I sometimes find it useful to compare what I do with coaching a sports team. Recently I was given the opportunity to put this theory into practice when I was invited to coach a national team at the World Orienteering Championships.

One of the most important jobs of a scrum master is to ensure that the day to day work of the team runs smoothly. Above all a happy team is a productive team. Likewise a happy team of athletes will get better results. So this was one of my main targets when going into the World Championships – shield the runner’s from any external problems and create a positive atmosphere.

You might think that a coach would spend most of his time telling the athletes what to do. But for a team of experienced international athletes there’s not an awful lot new to tell them. In fact I found myself working more like a facilitator – stimulating discussions, and encouraging the athletes to come up with their own solutions for handling the race situations. Very scrum masterish!

Of course there are differences too. Running a major championship is more comparable to releasing a system rather than working in scrum sprints. Though this is just what the athletes do in the run up to a major race. Using short, medium and long term goals they work incrementally towards the big release date.

So how did it go? No medals this time but some successes as well as a few disappointments. Now I hope there will be a chance to do a retrospective with the team – I’m sure that would help them get better results next time. And help me to do a better job, if I’m asked to help again.

Fitnesse refactored

We have put a lot of effort into automated testing. Not just unit testing but also system testing with Fitnesse. But it has come at a cost. In particular creating and maintaining our Fitnesse fixtures has become a burden.

In theory, Fitnesse should enable our domain specialists to write tests while the developers can get on with developing the features.

So far we haven't reached this nirvana.

For each major new feature we find ourselves either having to change our current fixtures or develop new ones. This taxes our development resources and our system tests lag behind development instead of leading it.

We must be able to do better than this.

Recently I've been wrestling with our fixtures - refactoring them to reduce the development debt. Finally they're starting to smell a little sweeter.

Here are some principles which have guided me ("best practices" if you like)

Principle 1. Structure fitnesse tests like unit tests.

They should have three distinct sections:

• setup the test data
• exercise the code to be tested
• perform assertions on the result

Principle 2 (corollory to Principle 1) Create separate fixtures for each of these phases.

One fixture say for priming the database with data. Another fixture for performing a query. And a third fixture for checking the result of the query.

Principle 3. Names are important.

By taking advantage of "graceful names" and choosing method names carefully our tests become more readable. They now look lke this:

|object id | is in query result? |

instead of

|objectId | checkResult?|

Principle 4. Fixtures should be tested too.

Writing unit tests for fixture code speeds up development and improves the quality and design of the fixtures.

Principle 5. Use dependency injection to decouple fixtures.

We use Spring to inject database connections, JMS queues and domain specific beans into our fixtures.

Nothing too radical there of course. But hopefully by concentrating on these key practices the returns from our investment in Fitnesse will improve.

Service Registry Manifesto

How should you go about creating a service registry? I've been working on this recently and the more I dig into it, the more I agree with the ideas expressed by Martin Fowler when he wrote about a Humane Registry.

Inspired by this article and also the Agile Manifesto I came up with a service registry manifesto. Namely, we should value:

• clarity and conciseness over detail and completeness
• flexibility and expandability over specification and planned structure
• integration with existing sources over creation of new content
• encouragement of use over contractual restrictions

That is, while there is value in the items on the right, we value the items on the left more.

Coincidentaly, after I created my manifesto, MF himself gave his seal of approval for using this type of list when he blogged on Comparative Values.

Sniffing out success

Recently, I found myself discussing code smells with a colleague. How do you recognise them and how can you fix them? Reading about refactoring and design patterns is certainly one way to train your olfactory sensitivity. But study alone is not enough.

In a previous life I was an elite orienteer. When I was racing to the limits of my ability one of the key success factors was reacting to mistakes and correcting them before they caused time loss. A bit like fixing code smells really. Nipping small mistakes in the bud before they grow into major time wasters.

As an orienteer I learned early in my career that the key to perfecting this skill is training, training and training. I'm convinced this is also true for the programmer. Mastering the skill of sniffing out code smells and cleaning them up comes only with practice - lots of it.

And just like the very best athletes, you should never be really satisfied. Skills need to be maintained with constant training, and there's always always room for improvement.

Pain Threshold

Finally the pain got too much. Once again I'd committed broken code into our Subversion  repository and the build server was glowing an irritating red.

It was a silly mistake and it wasn't the first time I'd made it. I'd run the test suite before committing but hadn't noticed the failing tests. Why? Because from Eclipse  we use ant  to execute maven. And the maven exit code is zero even when a build fails. This means that although maven writes "BUILD FAILURE" to the log, ant has the last word and logs "BUILD SUCCESSFUL".

Once again I'd been fooled by the bottom line and missed the critical text a few lines above it. It really was time to find a remedy for this affliction. It took a little bit of rooting around in the ant documentation but I eventually found a cure I could swallow:

<target name="_execute_maven">
<echo>mvn ${line}</echo>

<exec executable="${mvn}" dir="${execute.basedir}">
   <!-- save the log to a property too -->
   <redirector outputproperty="test.out"
                 alwayslog="true" />
   <env key="JAVA_HOME" path="${java.home}" />
   <env key="MAVEN_OPTS" value="${mvn_opts}" />
   <arg line="${line}" />
</exec>

<condition property="fail.status">
   <!-- search property for failure text -->
   <or>
       <contains string="${test.out}"
                         substring="BUILD FAILURE" />
       <contains string="${test.out}"
                         substring="BUILD ERROR" />
   </or>
</condition>

<fail if="fail.status" />
</target>

Why don't we use the maven plugin for eclipse? I don't know the definitive answer to this and it niggles me. The eclipse/maven/ant combination came with the project. A buggy maven plugin I'm told, but I ought to dig into this a bit more.  But so far this niggle hasn't breached my pain threshold.

Design Last

Kent Beck turned software development on its head when he popularized test driven development. By now we all know that we should be writing our tests as we write our code. 

I think it was also Beck who encouraged us to listen before we test before we code before we design.

But it's not just the change in the order of doing things that's important. Another key element is to listen, test, code and design iteratively. Not three-week-rup-iteratively but 10-minute-agile-iteratively. 

So if you ever catch yourself tagging "and Design" onto "Analysis",  lie back and think of Kent.

Notepad Revival

I've always been suspicious of programmers who use Notepad. And I'm not alone. As the Pragmatic Programmers  said "it's like using a teaspoon as a shovel". Perhaps I shouldn't be so prejudiced. Recently I've caught myself using this much scorned text editor. More often than I'd like to admit.

So what do I use Notepad for? The clue is in the name. Notepad is extremely good for jotting down notes. And the reasons it's good for this are that it's fast, lightweight and simple.

It's great for creating short todos, keeping a work journal or noting all those things that occur to me during a sprint but which are forgotten when the retrospective comes around.

But why the notepad revival now? The answer is Dropbox. Suddenly I can effortlessly save my jottings on my laptop, update them on my home machine and read them on my work box. 

Which doesn't mean you should even think of using Notepad to code java, create xml or check logs. 

Building Bridges

Anybody who tries to compare software development to building bridges doesn't know what they're talking about. Or so I thought, until I stumbled across some research from the construction industry.

The research in question was a study into the lack of efficiency in the Swedish house building industry. OK, not exactly bridges but houses are close enough for me. The study report's  main conclusion was that building projects are actually very inefficient and savings of up to 50% could be achieved.

I was reminded again of this report while attending a ScrumMaster course which we had arranged in Falun (thanks Henrik for two days of enlightenment).

And the reason I was reminded of it was that most of the recommendations the report made could have come straight from a scrum manual: 

•  focusing on delivering value to the customer
•  eliminating activities that don't deliver customer value
•  creating cross functional teams with customers and suppliers working in partnership
•  empowering and encouraging workers to improve their own processes. 
  

Perhaps it is time to start dreaming of building bridges like we build software!  

Scrum building

You're probably as tired as I am of hearing that we ought to be able to build software like we build bridges.

Nevertheless, I was reminded of this cliché while recently attending a scrum master course. Well actually, what I was reminded of was a report into the lack of efficiency in the Swedish construction industry. The research considered house building but that's close enough to bridges for me. The main conclusion was that building projects are actually very inefficient and savings of up to 50% could be achieved.

And the reason I was reminded of this report was that several of the recommendations made could have come straight from a scrum manual.

From focusing on delivering value to the customer and eliminating activities that don't deliver customer value.

To creating cross functional teams with customers and suppliers working in partnership.

And empowering and encouraging workers to improve their own processes.

If they're not already using scrum in building projects it sounds like they ought to give it a try. Perhaps its time to start suggesting they should be building bridges like we are now building software!