On Thursday 27 March 2008 12:42:13 Eric Wilhelm wrote: > What do you need to test that your users need to drive?
Business rules. > How can it be expressed in a non-tedious and yet understandable way that > makes them feel like it is a worthwhile process? That's the guiding design question of FIT tests. > At that point, you're pushing so much data into the test that it has > become tedious for the user to own (create, manually review) the time > cards, so you really only want to involve them at the configuration. > But you're getting much better test coverage (and presumably the engine > has been thoroughly flexed by feeding it various configs) and not > writing new code for every variation on a theme. Don't mistake FIT tests for unit tests. You'll stab someone if you do. > So, I can see where Fit could be useful in funnelling data from the > requirements gathering directly into tests, but I've yet to see an > example where it would both be tolerated by the users *and* provide > effective test coverage. Particularly, the tabular implementation is > so restrictive that expressing the "user model" of the software might > not be possible in that form. Of course. It's not for testing user models (if by "user model" you mean what a user interface designer means). > I like the concept, but how do I apply it to interactive software (gui > or web) where you have an initial state, action, and expected result? That's like deciding that it's impossible to test state machines because you don't know how to test the GUI for a state machine. -- c
