That is what I am doing as of now. Its just that JUnit test cases begin to
grow and grow and when I noticed how lisp-unit and even the JB tester are
implemented, they were a little more clean cut and fit better for testing a
rulebase than just making many Unit tests that (create rete object, batch
CLP, shove in fatcs, and try to get results out).
I am in a situation where I will not be able to modify the beans used in
the fact base, they are read only, so I have no luxury of the rules setting
a flag in the bean and having JUnit check to see if the flag was set. So I
am currently using a String Writer and grabbing the "t" output router. Then
doing horrible string.equals in my test cases to see if the expected result
is what I expect. Aside from watchAll() dumping everything, is there a way
to just check if certain rules fired in a Rete object by passing in their
name?
Something like the following would be ideal, if there was a boolean
RuleFired method:
@Test
public void test_Rule_1_Fired(){
//Lets just forget about the Try/Catch blocks for now...
Rete engine = new Rete();
ExampleBean b = new ExampleBean(12345,first,last);
engine.add(b);
engine.batch(rules.clp);
engine.run();
boolean result = engine.RuleFired("rule-number-one");
assertTrue(result == true);
}
Does something like RuleFired exist and I just missed it in the
documentation?
On Fri, Nov 13, 2009 at 10:59 PM, Wolfgang Laun <[email protected]>wrote:
> You can create a Rete object and feed it with rules and facts from Java
> code. So you could use JUnit to test individual rules with different fact
> combinations. I see no reason why this should not give you satisfactory
> results. Also, notice that the Rete mehod eval lets you pass gobs of CLP to
> a Rete object.
> -W
>
> On Sat, Nov 14, 2009 at 1:03 AM, Socrates Frangis
> <[email protected]>wrote:
>
>> Ive been looking around for any good implementation of Unit Testing on
>> Jess Rules. LispUnit http://www.cliki.net/lisp-unit provides something
>> similar for Lisp and I've been messing around with JUnit and 'shoe-horning'
>> inputs / expected results. Just wondering if anyone has came up with a
>> productive way of testing declarative programming when only something
>> procedural (JUnit) is available.
>>
>> -Socrates Frangis
>>
>
>
