# from Michael G Schwern
# on Friday 28 March 2008 00:30:
>> 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.
>
>I'm confused by that response. FIT is declarative.
It declares the inputs and outputs, not the business rule. Where the
table full of numbers is somewhat opaque, a table of rules would more
compactly express the business knowledge directly and readably -- the
payroll example seems to assume that all of the pay schedules are
spelled-out in a multitude of classes with piles of if() statements.
I'm saying that having the users write their rules directly in a
configuration (or DSL) would be more effective and understandable.
That is, an engine which lets the user directly formulate the rules in a
declarative form does a better job of bringing the client into the
development process and letting them own the rules than a pile of
blackbox input/output data which has to be manually calculated and
checked (possibly by the programmer.)
So, what place does Fit have?
| employee type | max hours | overtime | holiday | holiday + |
--------------------------------------------------------------
| standard | 40 | 1.5 | 2 | Sun |
| nights | 40 | 1.5 | - | - |
| temp | 40 | 1.5 | - | - |
Similarly for tax withholding, though there you might end up with
subrules which refer to another table.
So, instead of trying to state every input and output, we can see all of
the rules clearly for all of the different sorts of employees and they
address all of the various situations. No, this isn't a test
methodology.
>Part of the point of FIT is the method of inputing and evaluating the
>test results is comfortable to the user, not the programmer.
Do the users *want* to be inputing and evaluating test results?
>Categorization is a nice example.
>
>| URL | Category |
>---------------------------------------------------------
>| hooters.com | Restaurant |
>| whitehouse.com | Porn |
>---------------------------------------------------------
Now I'm really confused. That looks like tabulated data, so what code
would it be testing?
Your earlier example of "this page contains this contact info" for a web
scraper was probably more effective. But, that's monkey-work and not
business rules.
>> 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.)
>
>same way you determine any other test. You run coverage analysis.
Let me pretend that I didn't say "edge cases". How do I know that the
algorithm I implemented is the one they wanted and not some other
member of the infinite set which can produce the given input/output
pairings? If we're missing a critical set of data, we end up
completely rewriting code. (Yes, that's true in any methodology, but a
table of digits seems more apt to cause such an oversight than a
smaller and more readable table/list of rules.)
If Fit is about having the customer drive the *tests*, I guess it does
that. But I thought the goal was to have them drive the development
and give them a way to express the business rules -- in which case I
still can't think of a convincing example where it would be better than
the alternatives.
--Eric
--
As an old bass player friend of mine used to say: throw money, don't
clap.
--Tony Parisi
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
