Ok so obviously that’s not me saying that….
As part of thinking about the shape that ASP.net Fitnesse should take, and making certain design decisions around the system it’s unavoidable to think about how we’ve used the original Fitnesse in the past…. and it would seem that the certainty I’ve had in the past that the way I’ve used it has been the best and only real way to use the server, it seems that I’m sadly very mistaken.
Previously I’ve seen the ideal Fitnesse set up as being a one stop documentation for how a product should work.
The power of Fitnesse are the following
- Quick – no messing about making sure everything is in the correct format to be expected by a document management system or a requirements management system… got a requirement? just create a new page for it we can sort it out later.
- Unbloated – it’s just a simple wiki with a test function
- Instant feedback – just click test and find out how close you are
- Requirements + documentation all in an easy to read and understand format, put as little text around as you like/need.
- Tests are the specification – it really does push test driven design at a higher level than Unit tests
So my old way of laying out Fitnesse [that worked really well]
-> main wiki page –> current release in progress branch –> stories for release
–> previous releases –> regression stories
–> extra info –> pages and pages of other information we wanted to document, meeting minutes, design decisions, links… anything just not requirements.
now the CI integration is the most important part (without feedback on a regular basis why do you bother putting it in in the first place)
We had regression tests which would hit all the story tests from the previous release and FAIL the build if any of the story tests failed we felt this was an important aspect as requirement story tests were just as important as Unit tests
We also had a currently in progress build that would run and pass no matter what, it was more of an indication of how close we were getting to complete our requirements for the story.
so we’d do the following in the builds test phase.
- Current release FIT tests (always allowed the build to continue)
- UnitTests (fail build if they fail)
- Regression FIT tests (fail the build if they fail)
this would only be put into the nightly build (unit tests would be run on any build)
This worked really well for our team, but now I’m having trouble realizing how any other way of organizing the StoryTests could work beyond the following problems
- Old stories were hard to keep in step
- Stories were hard to find by functionality
- Some fit tests could be slow
So has anyone got a better or different way of working with Fitnesse?