Drools for test case formulation

I am testing a rather complex system, which behaves according to some business rules (written as semi-formal text).

The goal is to create test cases, which cover as many states of the system as possible. I want to automate this task in the following way:

1) 开发者_开发百科Formalize the business rules in Drools 2) Then use some mechanism to create a list of all possible situations (which need to be tested)

For example, I have following business rule package with two rules (this is only an example, real business rules are much more complex):

global List outErrorCodes;
global Boolean condition1;
global Boolean condition2;
global Boolean condition3;

rule "01"
    when
        eval( condition3 == false);     
    then 
        outErrorCodes.add("ERROR_CODE1");
end

rule "02"
    when
        eval((condition1 == true) && (condition2 == true));
    then
        outErrorCodes.add("ERROR_CODE2");
end

condition1, condition2 and condition3 are inputs. outErrorCode is the output.

That is, condition1, condition2 and condition3 describe a certain situation, and outErrorCode describes the expected behaviour of the system in that particular situation.

I want to create a mechanism, which automatically creates a list of all possible tuples (condition1, condition2, condition3, outErrorCodes), based on the logic in the rules. Each tuple represents a state of the system.

These tuples will then be used as a basis for creating actual test cases.

Is it possible with Drools? If so - how?

Many thanks in advance

Dmitri

We had success in taking the ruleset, deploying it as a service using drools-server, and then writing a script to make web service calls exercising each possible value of each input variable. Within about an hour we were able to make 5000+ calls to our rule base and see output for each case.

The downside (and I don't think you will get around this with any solution) is that you are testing business logic. When you think about it, you can generate all the test data you want, but you can't generate test input and an expected result without running the business logic (which you are testing). Just saying that if you get into auto generating input to business logic, you can't actually know the expected results without violating the integrity of the test.