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.
Usage like this: >> more…
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. >> more…
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.
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
Set symbol to the result of getFun():
| value | =getFun() |
| 3 | symbol |
Set param to the value of symbol:
| param= | setFun() |
| symbol | true |
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: >> more…
