Can someone help explain Fit Testing to me? [closed]

Question

So this is something that has been at the back of my mind for a while. I've seen mentions of it, I've read the fitness web page and I still don't quite grok it. It seems like Fitnesse is yet another testing framework like NUnit or MbUnit or any of the others because you define inputs and outputs that you want to see but it seems to be aimed at testing the application as a whole rather than as units.

If that is so, how does it run? Do you have to design your application with hooks for fit testing? Where on the spectrum of testing does it actually fall? And can someone give me a good example of where and how fit tests could be used and what are some advantages/disadvantages?

Answer 1

The difference between NUnit/MbUnit and FitNesse is that NUnit/MbUnit are intended to be used for unit tests, while FitNesse is for acceptance tests.

Unit tests test a single, small unit of code, such as a method, to ensure that it executes as the programmer intended. For example, you might use a unit test to ensure that a factorial-computing method returns the correct results for a set of numbers, including some edge cases.

Acceptance tests are intended to test whether a high-level design requirement is met. As an example, if you were writing a Pac-Man clone, and one of the requirements was "A new level begins when the last dot of the previous level is eaten," an acceptance test would test to see whether that requirement as a whole is satisfied by the code--not the specific pieces of code that consume a dot, check ending conditions, and load new levels (although that code would be exercised in the process of running the acceptance test). Acceptance tests typically are written without regard to the specific implementation of the requirement.

A lot of QA departments execute long lists of acceptance tests by hand, which can be very time consuming. Fit and FitNesse are tools that assist in automating acceptance tests, which can save a lot of time.

There's a lot of good information on acceptance tests at Ward Cunningham's wiki.

Answer 2

The last company I worked with used FitNesse with some degree of success. Its not meant to be used in the same way as NUnit, in which the degree of testing is very granular. FitNesse is used more for "acceptance testing", involving less granular, "large scale" tests. To compare the two, lets say we were writing an app for processing checks at a bank:

• If we're writing unit tests with NUnit, we'd test each individual method of our Check objects, Transaction objects, TransactionProcessor factories, test each method of our Data Access Layer, etc. You're tests are very close to the source code.

• If we're writing acceptance tests, we might set up a days worth of transactions, prompt the app to process the transaction, and make sure that the code produces the correct invoice statements and reports. You're at a much higher level than unit tests, usually at a vantage point where you can test all the applications business rules at once.

Unit tests tell programmers whether the code contains any defects, and acceptance tests tell business analysts that the applications meets user expectations.

FitNesse test cases are designed to be written by people without technical knowledge. You still need programmers to write the DLLs to expose the innards of the application to FitNesse, but otherwise the use cases are supposed to be written by non-technical people who don't know anything about the source code (i.e. business analysts and QA).

My company used FitNesse to test one of our "core" applications, which happened to be written over the course of 20 years using a dead COBOL-like language. The core app did not have unit tests, and it was nearly impossible to create a unit testing framework in the original language. Forturnately, the language had COM bindings which exposed a few public methods to .NET and Java, allowing us to write automated test cases for this application for the first time in 20 years. It wasn't pretty, but the business people liked it.