Here’s the video from last week’s Effective .NET Test Driven Development FitNesse workshop. The workshop focused on introducing agile acceptance testing and working with FitNesse, with best practices and ideas how to use fixtures efficiently. The recording is about two hours long.
See also:

• Key ideas from the workshop
• Source code and the missing example

Unfortunately, we did not have enough time to finish the example of integrating entity classes into FitNesse for .NET during the workshop. So here is the implementation:

Integrating FitNesse with Entity objects

Unlike value classes, where we can add a Parse method without any consequences, for entity classes the situation is not that simple. Entity objects cannot be easily “parsed” from a string, but there will typically be a way to find or create entities based on the description that will appear in FIT tables. Of course, the entity class, which is part of the business model, should not depend in any way on FIT classes. The dependency should work the other way round.

A solution that does not require any changes to the entity class code is to implement a cell handler for the entity type. Cell handlers tell FIT how to process the cells, and they are selected by cell text format and underlying object type. In this case, we just create a cell handler by extending AbstractCellHandler for the entity type and override the Parse method. That method should then execute the appropriate finder.

public class PlayerCellHandler : fitnesse.handlers.AbstractCellHandler
{

        public override bool Match(string searchString, Type type)
        {

            return typeof(Player).Equals(type);
        }
        public override object Parse(Fixture theFixture, Parse theCell,
           TypeAdapter theAdapter, object theTarget) {
            return Player.FindByName(theCell.Text);
        }
}

Unline the Parse method in the value class, the handler does not work automatically, it has to be activated using the CellHandlerLoader table (release 1.5 allows you to do this from a configuration file as well). If you want to use it in FitLibrary fixtures, then specify fitlibrary as the second argument to the load command. Here is how everything works together:

!|roulette3.PlayerStory|

!|CellHandlerLoader|
|load|roulette3.PlayerCellHandler|fitlibrary|

|Player|John|places|10|chips on|20|

|Player|Paul|places|20|chips on|11|

Agile acceptance testing

• It’s not about testing at all — it is more about flushing out enough examples before development, and using those examples as a target for work.
• It’s about building a shared understanding and making sure that everyone on the project has the same target in their minds
• User stories are the scope for development, (acceptance) story tests are the specifications.
• Business people, developers and QA all have different things on their mind, and view the system from different angles. Get them all to work together to produce the best results. Business people will have a better overview of the domain, developers will spot inconsistencies and QA engineers will suggest edge cases that should be verified.
• Describe-Demonstrate-Develop is a great way to think about the whole process
• Unit tests and acceptance tests complement each-other. “xUnit insures the code is built right, and FitNesse insures the right code is built.” (Andrew Dassing on FitNesse Mailing list)

FIT/FitNesse

• Tables describe tests — both inputs and expected outcomes
• FitNesse allows you to manage and execute tests easier, build test suites and organise the tests.
• FitNesse stores tests into text files, and they can be easily stored in the same version control system as the code. Folder-based systems like SVN might have some issues with refactoring, so don’t use FitNesse refactoring when you keep files in Subversion. Also, turn off automatic archiving and property updates (-e 0 -o)

Writing FitNesse tests

• Start by identifying and analysing the business rules.
• For each rule, roughly decide whether it is more like a tabular calculation rule or a story.
• For tabular calculation rules, use ColumnFixture and CalculateFixture
• For story-like rules, use DoFixture and SequenceFixture. Those fixtures can work in Flow mode and coordinate other fixtures as well.
• Symbols work with FitLibrary in .NET as well, but you have to add this table to the page:
  

  !|Cell Handler Loader|
  |load|SymbolSaveHandler|FitLibrary|
  |load|SymbolRecallHandler|FitLibrary|
  

Writing Fixtures

• Fixtures are a very thin integration layer.
• Use a public static Parse(string) method to allow FitNesse to automatically bind your domain types to table cells
• .NET version supports Target objects that can save a lot of code by not requiring you to re-declare the DTO properties in fixtures.
• Alternating Target Object pattern: use the first column to initialise the target object. All other columns are bound to the target object. Use Reset() to clean up after a row is executed.
  

  !|Bet placement and payouts|
  |fields|bet name?|payoff?|
  |30|Straight Up|35|
  |11,14|Split Bet|17|
  |19,20,21|Street Bet|11|
  |25,26,28,29|Corner Bet|8|
  |Red|Red Or Black|1|
  |3rd 12|Dozen|2|
  

  public class BetPlacementAndPayouts:fit.ColumnFixture
      {
          public Bet fields;
          public override void Reset()
          {
              fields = null;
          }
          public override object GetTargetObject()
          {
              if (fields == null) return this;
              return fields;
          }
  }
  

• Use the SetUpFixture instead of ColumnFixture to prepare the data or create new objects
• Use the System Under Test feature of DoFixture and SequenceFixture to bind tables directly to your business services and classes

Update: Download the source code and the missing example

See http://skillsmatter.com/net-tdd-fitnesse/pcd/5013 for more details.