# from chromatic
# on Thursday 27 March 2008 13:02:
>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.
So, what is a good example of such a business rule? I posit that
payroll does not count because the user could more concisely write the
rule in a declarative form, this isn't Java, &c.
>> 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.
That's conveniently intuitive then. So where do I get the guiding
design answer? Or at least, how do you decide when to be asking the
above question vs when to be asking "how do I set this up such that the
business rules are 'programmed' directly by the users?"?
>> 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. ...
>Don't mistake FIT tests for unit tests. You'll stab someone if you
> do.
Okay, so how do we be sure that the business rule is fully expressed by
the Fit input? (That is: guarantee that there are no edge cases.) Or,
is this one of those complicated things where worse is better because
we don't like better better than worse?
--Eric
--
"Time flies like an arrow, but fruit flies like a banana."
--Groucho Marx
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
