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