Table: and Query: prefixes no longer needed - FitNesse improvements Part 2

This is the second of a three part series into some new changes in the latest release of FitNesse. The first part was about easier ways to debug Fitnesse for .NET

In this installment we look at a a small change that means that query and table tables no longer have to specify their table type each time. This is useful for improving the readability of specifications/tests written in Fitnesse.

For example, tables that used to have to be written with a "Table:" prefix like this one

can now be written as

Now, this may seem like a comparatively minor improvement and in many ways it is. However, it is small, but worthwhile improvement because it touches on one of the most important principles of Specification by Example, which led to the development of FitNesse.

The principle I am talking about is that specifications/tests should be written so that they are understandable to the whole development team, including the business people. In particular, this means test/specs should only specifies what is being checked. The details about how to get the test to run should abstracted into the fixture layer or the setup.

The old “Query:” or “Table:” text belongs very much in the later category. It's an implementation detail that tells FitNesse how to interpret the table. It's about how to run the test and that is why it should be removed where possible from the specifications. FitNesse still needs to know how to interpret the table, so we still need to put this information somewhere.

How to specify a default table type for a table

Firstly, we still need to tell FitNesse how to interpret tables which are not decision tables. This is done by using a “Define Table Type” table which has the format shown below.

|Define table type |
|Bowling | as Table |
|BowlingHistory | as Query | 

This table should be listed straight after any “Import” tables and should be hidden away with other execution-only details in a SetUp page. Once this table has been defined we can use the table with out a prefix.

Now many programmers working on FitNesse may find it a little bit unreasonable to get so worked up about such a little word. You might think, “surely, business people can just learn to ignore anything that comes before the colon”. And you are right they can. But the problem is that FitNesse has lots and lots of little details that must be learnt and many people find that a big ordeal. So, in order to get business people more involved – which is after all the aim of such a tool – I think it is important we keep coming up with ways to make FitNesse simpler to learn

How to debug FitNesse .NET in Visual Studio - FitNesse improvements Part 1

This is the first of a three part series where I introduce to FitNesse users out there the changes I have recently made to FitNesse. In doing so, I hope that these improvements will not benefit more teams using FitNesse but over time FitNesse will be moulded into a tool that really allows us to fully live the vision of specification, or even documentation, by example

The first in these series covers a new way to debug FitNesse when using C# and other .Net languages. It has always been possible to debug FitNesse using RunnerW.exe instead of Runner.exe, but it was fiddly to find the right process to connect to each time when using Visual Studio.

So while working with the team at Emendo, we decided it would be much easier to debug FitNesse if we started the runner through Visual Studio.

There's a few steps you'll need to go through to set it this up, but once you have done that it works like a charm and then debugging starts with two button clicks!

Debugging set up

Step 1: Tell FitNesse that when you remote debug you want to start the runner yourself.

Add the following line of wiki mark to the same page as where you tell fitnesse which dlls to use.

!define MANUALLY_START_TEST_RUNNER_ON_DEBUG {true}

Step 2: Configure Visual Studio to debug by starting runner.exe

In your Visual Studio project, go to the properties page and edit the debug page to start the runner.exe application when debugging.

Specifying the correct command line arguments for the runner is important. Luckily, FitNesse provides a way of finding out the settings that it is using – simply run the test you want to debug, and then click on the information icon at the top of the page (shown to the right of this paragraph).

Then you should see a page with a table like the following:

Copy the “command” string into the Visual studio, but first remove the first argument (since it is the runner and you have already specified it) and secondly make sure the last number is port 8085 – the default (but configurable) port that FitNesse expects to connect to when when it is running in debug mode.

Lastly, be sure to set the working directory to the one that FitNesse uses.

Setup is now complete!

Debugging a page

Now you are ready to debug your fitNesse test.

1. Start test in FitNesse in Debug mode by either

   1. clicking your javascript browser shortcut, or

   2. Adding ?responder=test&remote_debug=true to the URL for the page

2. Add breakpoints

3. Start debugging within Visual Studio

   
   

This setup should continue to work for fine for all your tests, so long as they all use the same set of dlls. However if you find you add another FitNesse dll you will need to update your command line setting.

If you have any questions or can't get this to work, please post them as a comment or send them to the FitNesse newsgroup and I will try to answer them.

Happy debugging!

ATDD using FitNesse course now available!

I am proud to announce that I have joined together with Clarus consulting to create a fabulous ATDD course based on FitNesse. So whether you are in Australia, New Zealand or further abroad, you can now get leading edge coaching to kick start the use of ATDD or FitNesse within your organisation.

However, this 2 day course covers far more than just learning how to use FitNesse. Instead it is a team based learning session during which the whole team, (BAs, testers, developers, product owners), works together to create executable specifications for a project. This experience should in

I've already helped many teams quickly increase their automated testing coverage while at the same time improving communication using FitNesse. And I am truly excited about the huge positive effects that those teams have continued to enjoy after I left. It is these experiences that I leveraged when writing the course.

So if you are ready to find out how to build the right software, and how to build it right so that you can confidently release the software time and time again, then get in touch right now by contacting me here.

Course Overview:

Topics for the course are taken from the following.

Day 1:

Introduction to ATDD

• ATDD – a new way of working
• ATDD vs TDD
• Why we should automate tests
• Why the whole team should be involved

Specification Workshop

• How to run a Specification Workshop

Writing up specifications (tests)

• FitNesse Wiki Basics
• Guidelines for writing executable specifications
• Tricks for writing specifications in FitNesse
• Introduction to FitNesse Automation

Day 2:

Making specifications (tests) executable

• Coding basic tables
• Structuring FitNesse code
• Setting up FitNesse for the team
• Debugging FitNesse code

Organising specifications

• Creating a fixture toolbox
• Organising specifications
• Suites in FitNesse
• Source Control and FitNesse

Advanced topics

• Dealing with legacy systems
• Solutions to common automation problems
• Overview of other ATDD tools
• Tips for successful FitNesse implementations

The course is suitable for teams who are completely new to FitNesse as well as those who are already using FitNesse but want to use it more effectively. Everyone should come away from the course with a solid understanding of how to use FitNesse to collaboratively build executable specifications. Teams familiar with FitNesse will also explore some of the more advanced topics in depth.