Fit Nesse

http://www.fitnesse.org | http://www.sourceforge.net/projects/fitnesse

'new FitNesse Release' march-01-2005. http://fitnesse.org/FitNesseDevelopment.FitNesseRelease20050301

(They also seem to have answered the ExtremeProgramming FAQ "how do you record finished UserStories?")

Andrew wrote: I'd love to write a port of FIT for VB, but I just don't get FIT or Fitnesse. Can anyone explain it _slowly_ to a real dense head?

FitNesse is:

A stand alone java program that requires no other .jar files or configuration to use. Download and go.
A very simple web server.
A wiki. Or rather, a hierarchical wiki. Each page can have subpages which act as completely independent wikis.
A vehicle for running FiT tests.

FiT is a {java,c#,perl,ruby,...} framework for interpreting html tables and binding them to fixtures that transmit the table cells to an application, and compare results from that application to other table cells. Fit generates a new html table that looks just like the input table except that the comparison cells are colorized and annotated. Green cells match the expected outputs. Red cells don't. Etc.

FitNesse is a collaborative tool that is designed to be used by developers, business analysts, and QA staff. Stories can be captured on wiki pages. Over time they can be embellished and elaborated with tables that demonstrate the detailed requirements of the story. Later fixtures can be added that allow those tables to communicate directly with the application. Thus the story grows from a simple statement of intent, to a full fledged requirement, to an automated acceptance test.

The intent is for business analysts to write the stories and, with the help of QA staff, to embellish those stories with detailed tables that specify the details of the requirements. Then the QA staff and developers instrument those tables with fixtures that bind the requirements specification to the application.

I haven't used Fitnesse, but here's my FIT explanation:

Many of us find tabular formats very natural for expressing the desired results from our programs. Many users seem to feel the same way. At least we see them scribble tables on yellow pads, write them on white boards, send us word docs with tables or create spreadsheets showing what they want from us.

Converting such tables to tests is often only mechanical. And the output of the tests ends up being in a non-tabular format - unless we post process them using my neat NUnit test result processor, which is another story entirely.

Since the two biggest words in XP are "What if?" we might ask ourselves "What if we could execute those tables?" Then we could just run them and - if the test results showed up in the same format - give them back to the user for review.

The next logical question would be "What would have to happen in order for this to be possible?" Ward's answer was FIT.

Depending on the particular table structure chosen, you can think of a table interpreted by FIT in several ways. Generally, it feels like a test fixture. In the simplest cases, where some columns provide input values and others provide the expected output, the rows can be considered as a set of parameterized test cases analogous to what you might get if you wrote several cases exercising a method with different inputs and then removed duplication.

The easiest way to understand the benefit is to do it. Look at some examples on http://fit.c2.com and then think of a table you wish you could execute. Shamelessly copy code from the samples and modify them using the predefined table formats that come with fit. Eventually, you'll think of something new and different you wish the table could do... derive your own fixture type and code away.

--CharliePoole (from the XpMailingList)

---

Even better, go to http://fit.c2.com/wiki.cgi?WebPageExample . Notice there's a quick test of google in the first table. Then there's a bunch of comments, then some more tests. Now click on the "run.cgi" link below the second paragraph.

Notice the red and greenness applied to the page. Green is tests that worked, red is tests that didn't.

The theory is that tables are an easier way to write tests. I personally think that's true for functional tests (but probably not unit tests), and I'll test that theory soon by playing with jwebunit attached to FIT. The other theory is that the tables and the green and red color-coding are very accessible and easy to understand. I personally think so. Please let me know if this helped.

-- SteveWiller

See also: FitLibrary, FitWiki [...through the SisterSite icon below, for example]

[Category: TestingFramework]