I’ve recently been looking at Fitnesse and integrating it into our application in order to provide our BAs with more confidence in the code we deliver as well as reduce the time it takes for non-developers to test our code out. A lot of our application is data centric, with complex logic carried out under specific circumstances as batch tasks etc. rather than having a front-end to see the results. Often we are relying on data that appears once in a blue moon – in order to “prove” that the code is working correctly, we generally end up creating fake data directly on the DB etc.
Now, you can write unit tests to prove your code does what its supposed to, but unit tests generally don’t cut it with users or BAs. That’s fair enough – unit tests should give developers confidence that the code does what we intended, but they don’t (shouldn’t) cross tiers, and they don’t test business scenarios.
Fitnesse allows us to construct tests in a pretty human-readable format, and write some simple adapters behind that map to your real code. The front end is simply a wiki site, the idea being that once you’ve done the grunt work of writing the adapters for the tests, the users can write their own tests (sort of like you might see with SpecFlow or something similar, except that this is a self-contained website rather than a VS tool) and see instantly what the results are.
The beauty of doing this is that you empower your testers or BAs to start writing acceptance tests that they can validate the system against. This gives them confidence that the system does what they expect, whilst also reducing the amount of “blind” testing that happens post-release i.e. just plugging your app against a DB and having a look through it to ensure that it “seems right”. More than that, as these tests are repeatable they form a regression suite of tests.
The documentation isn’t the best in my opinion, particularly from a .NET point of view, but there’s a very, very good free e-book that you can read through which will get you going. Installation of Fitnesse itself is easy, but the .NET dlls weren’t exactly clearly spelled out – indeed, one of the links on the Fitnesse site points to an obsolete .NET fitnesse framework. Once you get it up and running though, there’s not much more to it.
Don’t fall into the trap that I did when starting to write out tests – don’t reverse-engineer them from your unit tests or from implementation of a single method, with mocks etc. Instead, you should aim to have your tests cross as many tiers as possible – I mock out my data layer simply to avoid having to actually create a database etc., but aside from that, nothing is mocked. Your tests should really try to perform business-focussed tests – I try to think of it as each fitness page being a single test script. It might have a large set-up and asserting multiple items at the other end – to me, that’s fine, unlike unit tests where I sometimes want a test to only validate e.g. a single method call with the correct arguments.
The biggest “gotcha” I found with Fitnesse is that each page is considered a test, with it’s own setup etc. – you wouldn’t normally have multiple tests with their own setup in a single page (despite the simple examples you often see showing exactly this). Again, this follows the idea of having a page per “test script” rather than a page containing multiple unrelated tests.
I’ve only been using it a day or two but have already gotten some really good results – I’m expecting that I’ll use it more and more in future and would say that it’s definitely well worth a look.