Appendix B. FitNesse
This appendix gives a brief introduction to FitNesse—the acceptance test wiki. For a more in-depth material, check out the website at http://fitnesse.org. The book on Fit for Developing Software [MC05] covers also a bit of FitNesse, although the material is a bit dated. For example, it does not deal with the Simple List invocation Method (SLiM) tables, which Robert C. Martin introduced in 2008.
Figure B.1 shows the FitNesse architecture involving the two test systems—FIT and SLiM. The test cases are wiki pages organized in a hierarchical structure. FitNesse then either executes tests using the FIT client or the SLiM client. This is steered by defining a variable. You can redefine this variable inside the hierarchy thereby allowing you to mix FIT and SLiM tests—although all FIT tests will be executed separately from all the SLiM tests if you run the whole suite.
Figure B.1. The FitNesse architecture showing the two test systems
Behind the process boundary, the FIT client and the SLiM runner invoke different methods based on conventions. These methods then involve the system under test in order to drive the tests or to gather certain results in the system itself.
The older FIT system comes with a GPLv2 model and uses inheritance to mediate between the tests and the application. Thus, all your fixture code becomes effectively licensed under GPLv2. I’m not a lawyer, but some companies didn’t like this licensing model, so Robert C. Martin came up with a test system that uses convention over inheritance. I will leave out the FIT discussion and focus on SLiM as the test system.
Wiki Structure
Wiki pages consist of a name in a camel-case format. A camel-case name for a page that deals with accounts reloading some balance could be AccountReloading. A camel cased name has at least two uppercase letters and no spaces.
Wiki pages in FitNesse can be nested into suites. You can use suites to combine parts of your system that belong together and should be tested together. FitNesse lets you execute the tests in a sub-suite in separation from the rest, while you can still execute all the tests from the top level or even a test at a leaf.
Wikis come in handy when you organize knowledge. Since you can link to other wiki pages, FitNesse let’s you create your test examples together with your written documentation, and basically all other necessary information like common flows through your system.
SLiM Tables
There are some table structures that you can use in order to express examples for your application. The most convenient table is the decision table. It consists of input values to the system and outputs that are checked after executing some operation. Listing B.1 shows an example.
Listing B.1. A FitNesse SLiM decision table
1 !|Traffic Lights |
2 |previous state|next state? |
3 |red |red, yellow |
4 |red, yellow |green |
5 |green |yellow |
6 |yellow |red |
7 |invalid state |yellow blink|
For sets of values there are query tables. These become handy when you have collections of data to check in your system. For example, you might want to check a list of accounts that are in your system or fulfill a certain constraint for your test. In a query table you list all the objects on one line each. You can define multiple properties that will be checked. Listing B.2 shows an example query.
Listing B.2. A FitNesse SLiM query table
1 !|Query:Active Accounts |
2 |account number|account name |
3 |123 |John Doe |
4 |42 |Jane Doe |
5 |24141 |Luke Skywalker|
6 |51214 |Darth Vader |
You can use decision tables and query tables together in a single test. Usually this means wrapping both in some execution plan together. This is where the script table comes into play. For decision tables you can leave out the checked outputs. The decision tables then become setup tables to create anything you need for your test. In a script table you then execute some action like working on a previously created account. In the end you may check the results of that operation in script instructions or query tables.
This format is similar to the Given-When-Then-format of the BDD approach we see in Cucumber. The setup table describe all the Givens, the script table action describes the When-step, and the Then-steps are checked by either script actions or by a query table.
This mechanism becomes more powerful when you use it in combination with scenario tables. Scenario tables let you extract common steps from script tables, which you need several times. You introduce a layer of higher-level abstractions with these scenario tables. It is similar to the keyword approach that Robot Framework (http://robotframework.org)—another Agile-friendly test automation tool—provides.
Support Code
Support code for the SLiM tables can be written in multiple languages. Java is the native one for FitNesse, but there are also SLiM ports to Ruby, Python, .NET, and PHP just to name a few. We will focus on Java here.
For decision tables, you have to implement a setter for each input column and provide a getter for each output column. The SLiM runner will automatically find the appropriate setter and getter based on the column name.
For query tables you have to return three nested lists of strings. The inner-most list represents individual cells containing the label of the header column and the particular cell data. These are combined for each line in the middle list. The outer-most list collects all the lists. It took me some time to get my head around this. Once you understand the clue, it becomes rather easy.
For script tables the name of the function that is called is constructed by camel casing the line. Parameters in each even column are forwarded to the function. A script table like the one in Listing B.3 would be translated to the method call scriptWithSomeParameters(String value1, String value2) at the class ScriptTable.
Listing B.3. A FitNesse SLiM script table
1 !|script|ScriptTable|
2 |script with|param1|some|param2|parameters|
For more in-depth material check out the FitNesse user guide and the tutorials from Brett Schuchert, which are linked on the main FitNesse entrance page.