Guitar Theory

When I was much younger, I use to play the guitar. For my first guitar, I had bought it at an auction at a market. The pickups didn’t work, the nut was missing, no strings, but I was determined to learn. So I went to the nearest guitar shop that did repairs and took it to them.

Several parts later, I had a working monster, and it was a monster, but it got me started.

Not long after, I got a new guitar. Not much better, it was the cheapest one I could get. It had only 21 frets, and the amp I got was a cheap and nasty from Tandy at the time. What do you expect, I was a poor student at the time. That was when I really learned to play, and so I practiced every chance I got.

One thing I heard or read somewhere at the time that has stuck in my mind is that having a very expensive guitar like the one your favourite guitarist plays does not make a bad guitarist good, they will sound bad regardless, but a great guitarist can make a box and strings sound great and a good guitar sound amazing.

So where am I getting at, well… In my experience, companies go and fork out hundreds of thousands to even millions of dollars for tools or frameworks to help with their corporate development thinking it will save them lots of money, make things easier and or get them there sooner and a lot of the time, these projects generally fail, cost a lot more money, take forever to get off the ground as they wait for approval to spend the funds or end up not being what was envisioned in the first place.

In these circumstances, the time to practice, the time to learn the fundamentals of what this new product is meant to make easier, the time to iterate over your procedures to learn what is the best way to implement, the time to become a good player has not been put in.

My advice is to start learning the fundamentals today. Use open source software (it may surprise you), build your own stuff, cobble together scripts, read, learn, practice. Just workout your own sound. Learn to play with that box and strings and make it sound good so that when you get your new shiny tool, framework etc – you will just sound amazing!


As mentioned in my previous post, Fitnesse is a product used to describe specifications using the Acceptance Test Driven Devlopment or Behaviour Driven Development methodology.

Fitnesse was created by Robert C. Martin (Uncle Bob) about 10 years ago and originally was based on the FIT language created by Ward Cunningham.

Fitnesse uses a wiki to write your specifications and fixtures written in multiple languages, but originally in Java.

Fit provides the ability to create :

Column fixtures : Where the rows represent inputs and expected outputs

Rows Fixtures : Testing queries that return an exact set of values (Ordered independantly)

Action Fixture : Allows you to write a script that emulates a series of events.

Comment Tables : Allows tabular comments that are not executed as tests.

Slim, the other language used by Fitnesse provides a lot more functionality.

Decision Table : Supplies the inputs and outputs for decisions.

Dynamic Decision Table : Same as the decision table, but passes column headers as parameters for the fixture.

Query Table : Supplies the results of the query.

Subset Query Table : Supplies a subset of the results.

Ordered Query Table : Supplies the expected result of a query in a particular order.

Script Table : Allows scripting a series of actions and checks.

Table Table : Allows you to write a fixture that arbitrarily executes as specified.

Import : Add path to the fixture search path.

Comment : Add a comment

Scenario Table : A table that can be called from other tables.

Library Table : A Table that installs fixtures available to all test pages.

Define Table Type : A helper table that defines the default table for named fixtures.


There are a number of advantages of using Fitness over using word for your specification documentation. These include…

  • Built in Version Control. You do not need to add your specifications to a version control system. Adding is supported but not required.
  • Its easy to see when your document is up to date. You simply run the test. If all is green, all is good.
  • The wiki is rendered to HTML. So you can export to to HTML documents or Rich Text format for those who would like to use Word.
  • You can use CSS to format your pages. So you can have everything company specific, team specific or however you like.
  • Built in User Access Control, so only registered users can modify the documentation.
  • There are a lot of plugins that can extend the functionality of Fitnesse.


Consequently, there are a number of disadvantages of using Fitnesse over Word.

  • Fitnesse requires coding to get the background tests done. None required by Word (given it can’t execute tests anyway).
  • Adds another layer of complexity, but saying that, I would say the benefits are greater.
  • When using XML messages as sample data, they are encoded to be visible within the wiki format. Therefore before you use them in your fixtures, you need to decode (ie change the < & etc characters) to get the original XML.
  • You also get formatting issues with using XML. ie, leading and trailing spaces that needs to be fixed by the fixture.
  • Editing the wiki text can be quite difficult if you have exotic formatting. I had some issues getting tables looking like they would in word where you have merged cells etc.
  • Not everyone is comfortable with a wiki, epecially non technical people. This was the biggest argument I had with my team about Fitnesse. I don’t think it is founded. Mind you, we had the same argument about Mardown.
  • Just like a wiki/HTML page, embedded images and attachments are stored in separate files.
  • You are not able to make the document as pretty as a word document. But then again, that isn’t the purpose.

Fitnesse is a very powerful tool and I think using it for specifications is very advantageous especially if you are using free form documents for your specs.  If your organisation is  adverse to change, this may be one way to bring Specification By Example tools in while keeping a similar document format to your current word documents.

Getting started with Fitnesse is easy. The documentation is very well written and can get you started very quickly.

I would very much like to hear if anyone else is using Fitnesse, especially in the SOA/Integration space and how you document your message formats. Please let me know in the comments.