Developers blog » Fitnesse

Fitnesse reject in do fixtures

Helga — Tue, 09 Feb 2010 20:11:42 +0000

There are more pleasurable things then wading through the fitnesse documentation with its table style, so whenever I don’t remember some fitnesse key word, I’d rather hesitate and wait for an inspiration before going there. This is to memorize the key words to be used in do fixtures.

show to print out non-boolean values
check to verify non-boolean values
reject to invert the logic of the test

Usage like this:

Do Fixture Test
check	fixture method	parameter	expected value
show	fixture method		parameter
reject	fixture method that will fail with		parameter

I was the latter, which caused some failing wild guesses and finally made me read the documentation. Some more useful keywords worth recapitulating were documented here a year ago.

Match multiline Strings in FitNesse

Christoph — Fri, 08 May 2009 08:54:59 +0000

Today we upgraded to the newest version of FitNesse (20090214) and suddenly all tests trying to match multiline Strings weren’t working anymore. We used the approach given here and defined variables that had line breaks in their value:

!define expected_result {some
multiline
text}

These variables could then be simply used in the test tables:

|${expected_result}|

But with the new version, line breaks in variable definitions are treated like spaces and the expected result becomes “some multiline text” without the newlines.
A different solution to get preformatted text, to use {{{ … }}}, isn’t working in test tables and therefore is of no use in our case.

So we decided to encode all occurences of \n by some simple comparable string (which isn’t used elsewhere most likely) in the fitnesse-tests and on the comparator side. If you have a better solution for this problem – please let us know!

Bringing our Fitnesse up to scratch

astro — Sat, 04 Apr 2009 11:56:43 +0000

Before each release the support guys click through the whole application (following a smoke test script) to prevent that new bugs sneak in. However, sometimes they don’t manage to find all of them. No wonder since humans just tend to make mistakes when doing such stupefying, reoccuring work. Apart from that, the procedure is awfully time consuming – eight days of development require two days of testing.
That’s why we decided to enhance our suite of acceptance tests. Now we use exactly those two days support needs for testing to write new Fitnesse tests. We first created a list of all parts of the smoke test which were not already covered by automated tests. Each pair of developers picks one of the tests, implements it and then the interaction design girls look over it to ensure its quality. That way we already implemented 2/3 of the missing tests. As a side effect we improve old Fitnesse tests we find while searching for “inspiration” for the new ones.
Because Fitnesse tests are run on our continuous build server after each commit, new bugs are found before the smoke test even starts.
And that pays off: In the last three iterations only one small mistake made it into the release! Customers and support love our improved Fitnesse.

Fitnesse Keywords

astro — Fri, 03 Apr 2009 19:48:01 +0000

Even after one year of writing Fitnesse tests I keep forgetting the keywords to check for empty or erroneous results and how to get/set fitnesse variables. So finally, here’s a short list to look them up:

blank: checks for empty strings
null: checks for null
error: checks whether any kind of exception occured

Fitnesse and Reflection

Christoph — Wed, 04 Mar 2009 12:45:04 +0000

We use Selectors that return a list of objects all over the application and of course we want to use them in our Fitnesse tests.

To be able to do so, we introduced a new kind of Fixture that uses reflection to fill a map – one entry for each result of the selector. Basically, all we did was expand Fitnesse’s RowFixture and override the query() Method:

@Override
public Object[] query() throws Exception {
final List> result =
new LinkedList>();
for (ValueObject each : executeSelector()) {
Map row = new HashMap();
for (Field field : each.getClass().getFields()) {
if (Modifier.isStatic(field.getModifiers()) && field.getType().equals(String.class)) {
row.put(field.getName(), each.getAttributeAllowingNull((String) field.get(null)));
}
}
}
return result.toArray(new Object[v.size()]);
}

executeSelector() is abstract and has to be overwritten in each subclass of this Fixture to return whatever is needed. In Fitnesse, you can directly use the the field names:

|User Selector|
|NAME|AGE|GENDER|
|Daisy|32|female|
|Donald|34|male|
|Minnie|25|female|

That way we are able to write slim fixtures and don’t have to waste time writing getters for each field as we did before.