Gojko Adzic

I’m getting this question very often from web site readers, and I’ve decided to put the answer online because it deals with a crucial misconception about FitNesse and signals a really bad usage practice. The question appears in different shapes, mostly around templating or simplifying complex scripts. This is the latest version:

I would like to know if we could used a Fitnesse page as a template.

We all know that Fitnesse offers ColumnFixture which allows us to make a loop within a wiki page. I understand that with a ColumnFixture, we could not run anything other than methods defined in that ColumnFixture. So if i need to run a test scenario over a set of parameters, i need to create a ColumnFixture, build a method which do all the work of the mentioned
test scenario, then put the ColumnFixture on wiki page….

The biggest disadvantages is that we have to develop something (the development curve could be expensive if the test scenario is rather complex) for each test scenario. Any way, this advantage will be overcome if we have ability to use a wiki page as template. Here is detailed description of using wiki page as template:

1. Build a simple Column Fixture encapsulating all parameters used in a test scenario *and* the absolute path of the page representing a single test scenario

2. Put the ColumnFixture in a third Fitnesse test page, with tuples of parameters in rows  *and *the absolute path to test scenario page in question

3.Click on the ‘Test’ button, then the wiki engine will run over all the table rows. For each row, tuple of parameters would be inserted into the template page specified by the absolute path. Then the filled template page would be executed as a normal Test page

4. The final test result will be collection of all..

There are several ways you can do this with FitNesse, including Markup Variables and Parameterised includes, but the problem here is not how to do that, but why do you want to do it at all. Posing this questions seems to suggest that you are building scripts rather than a specification with Fitnesse. This is a very bad practice and it is going to cost you a lot on the long run.

Reusing fixture code or fixture tables is not something you should be concerned about if you are using FitNesse properly. FitNesse is not a general purpose test automation tool. It is not designed to be a test automation tool, it is designed to work with acceptance tests or executable specifications that are worked out together by the business, testers and developers. Such acceptance tests can and should be used for regression testing later, but FitNesse is not a general-purpose test tool. There are much better tools for that, and if you need UI automation testing, use one of such tools.

FitNesse is a very good tool for executable specifications. In order for executable specifications to be effective, they have to be easy to read and understand and they have to explain the system from the appropriate level of abstraction. Otherwise they are unusable as a target for development and they will be a pain to maintain, especially because code refactoring does not propagate to test pages. Having templates and complex scripts does not fall under the “easy to understand” category. Looking at things from the proper level of abstraction means grouping related rules and explaining them so that there is very little which really needs to be reused across different specifications.

You should encapsulate the script (your template) in fixture code, and then use the table with parameters and results in the fitnesse page connecting to that fixture to specify inputs and outputs. This difference between the script (how) and specification (what) is the key to successful application of acceptance testing. Details of scripts and their complexity should be put into fixtures (and don’t force yourself to use the ColumnFixture, take a look at the fixture gallery and see which fixture type is closest to what you want to achieve). FitNesse tables should just provide inputs and expected outputs for entire scenarios, not dealing with individual workflow steps. Tests like that will be much easier to understand and maintain. Changes in code will be propagated to fixture code, so you will not suffer from high maintenance costs. David Peterson gives a very good example of the difference between Scripting and Specification on Concordion Technique page. The ideas described there are applicable to FitNesse as well.

Some testers complain that this requires developers to help them with writing fixtures. If you do not work together with developers, then you are not doing agile acceptance testing properly and there is no chance that the whole thing will actually work. So not having developers on board is a much larger problem than the one of writing fixtures to automate your tests. Again, this may signal that you are not using FitNesse for agile acceptance testing but just for test automation, and there are much better tools for that. Use the right tool for the job, don’t treat FitNesse (or anything else) as the silver bullet that solves all problems.

Get notified when I post something new - subscribe via RSS or Twitter!

Trackback URI | Comments RSS