# from Andrew Gianni
# on Thursday 01 March 2007 08:42 am:
>However, our business rules
>have gotten complicated enough that we are no longer writing them that
> way explicitly in the code. In the last application we built, we put
> the rules in a database and the appropriate ones were pulled based on
> circumstances (using generalized code) and run. Now we're embarking
> on something different that allows us to essentially write our
> business rules declaratively,
Assuming that applying a rule to some input yields a "verdict", you may
want to use data-driven testing and have the same users write data to
drive tests of the rules. They would use a spreadsheet or some other
means to create data which exercises the rules.
input1, input2, input3, expected verdict
Try to keep it simple (possibly breaking sub-conditions into a different
set of data or labels for a common group of inputs) so that anyone on
the business team can audit it.
I'm assuming "expected verdict" is one (or more) of a finite number of
answers that you get from your rules engine. (Possibly a method name,
key in a dispatch table, or input to a function.) If this is true,
then your application can be unit tested against each of the verdict's
action-points. Changes to the rules engine shouldn't break the
data-driven tests and thus shouldn't break the action points. Changes
to the rules require changes to the expected verdicts, and may require
changes to the action points, but at that point you should have good
coverage.
> although it's taken care of by a module
> that we can assume is fully tested (details will be forthcoming at
> some point, methinks).
I would like to see that. Please keep us posted.
--Eric
--
"Unthinking respect for authority is the greatest enemy of truth."
--Albert Einstein
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
