[TIP] Fitnesse testing

[Grig Gheorghiu]

--- David Montgomery <davidlmontgomery at gmail.com> wrote:

> 
> Not long ago on this list Grig wrote "glad I managed to convince
> you of the utility of Fitnesse", and he mentioned that PyFIT/Fitnesse
> was included in Grig's and Titus' testing tutorial at PyCon.
> 
> On the other hand, during PyCon I noted that Titus said (during
> the testing tools panel, I think) that he thought the entire idea
> behind Fitnesse was misguided or misconceived.  Something like
> that.
> 
> So I would be curious to hear them (and others) discuss this
> further.
> 

Hi, David

First of all, I don't recall Titus expressing his opinion of Fitnesse
in those strong terms :-) It's true he's not its biggest fan either. 

I hope others on the list who have tried using it and either liked it
or hated it will jump in with their opinions too.

First of all, let me say that Fitnesse is a tester's tool more than a
programmer's tool. Its purpose is to express acceptance tests as
'customer-facing tests' -- as opposed to unit tests, which are
'programmer-facing tests' (Brian Marick came up with these terms I
believe). 

In an agile environment, where functionality is added in an iterative
fashion and expressed as stories, Fitnesse is a great way IMO to
capture the acceptance criteria for those stories in the shape of
tests. These tests are written as examples, in a table format, with
inputs and their expected outputs. One of the theoretical benefits of
Fitnesse is that customers (in the XP sense, but you can also think of
them as business analysts), testers and developers sit together and
compose these 'storytests'. The act of composing the storytests and the
ensuing discussions help the participants deepen their understanding
about what exactly they need to provide to their customers at the end
of the iteration. I say 'theoretical', because in practice these
discussions might not happen that often, or might involve only a small
subset of people.

One of the main values of Fitnesse is that, because it's a wiki, it
offers a way to write 'executable documentation' about the features
you're trying to add. This is because you can intersperse free-flowing
text with test tables, and run the tests on demand. You can achieve
this with doctests too in Python, but the advantage of Fitnesse is that
tables can show many examples of a feature at a glance -- whereas to do
the same with doctests would require adding examples sequentially,
makind them harder to read.

Fitnesse can serve as the hub of your testing infrastructure, at least
for your acceptance tests. It provides a better visibility into what
exactly you're testing. You can also run Fitnesse tests from the
command line, and schedule them to run in a continuous integration
system such as buildbot.

I can go on, but I hope somebody else will jump in too.

Grig