[rules-dev] writing unit tests

Mark Proctor mproctor at codehaus.org
Mon May 16 22:16:36 EDT 2011


It's great when people attach unit tests to jiras, it would be ever 
better if they are just cut nad paste single files, rather than entire 
projects, which take more time for us to fiddle with. Also please do try 
and pair your actual program "main" examples down to minimal unit tests 
of the actual problem. If you suspect the problem is MVEL, then please 
do a minimal MVEL test, without Drools.

Put static classes in the same file, put rules in a concatenated string. 
This means testing is as easy as cut and paste for us, and it can be 
easily added to existing test classes. For example, from MiscTest.


     public static class A {
         private String field1;
         private String field2;

         public A(String field1,
                  String field2) {
             this.field1 = field1;
             this.field2 = field2;
         }

         public String getField1() {
             return field1;
         }

         public void setField1( String field1 ) {
             this.field1 = field1;
         }

         public String getField2() {
             return field2;
         }

         public void setField2( String field2 ) {
             this.field2 = field2;
         }

         public String toString() {
             return "A) " + field1 + ":" + field2;
         }
     }

     @Test
     public void testExistsIterativeModifyBug() {
         // JBRULES-2809
         // This bug occurs when a tuple is modified, the remove/add 
puts it onto the memory end
         // However before this was done it would attempt to find the 
next tuple, starting from itself
         // This meant it would just re-add itself as the blocker, but 
then be moved to end of the memory
         // If this tuple was then removed or changed, the blocked was 
unable to check previous tuples.

         String str = "";
         str += "package org.simple \n";
         str += "import " + A.class.getCanonicalName() + "\n";
         str += "global java.util.List list \n";
         str += "rule xxx \n";
         str += "when \n";
         str += "  $f1 : A() \n";
         str += "    exists A(this != $f1, eval(field2 == 
$f1.getField2())) \n";
         str += "    eval( !$f1.getField1().equals(\"1\") ) \n";
         str += "then \n";
         str += "  list.add($f1); \n";
         str += "end  \n";

         KnowledgeBase kbase = loadKnowledgeBaseFromString( str );

         StatefulKnowledgeSession ksession = 
kbase.newStatefulKnowledgeSession();
         List list = new ArrayList();
         ksession.setGlobal( "list",
                             list );

         A a1 = new A( "2",
                       "2" );
         A a2 = new A( "1",
                       "2" );
         A a3 = new A( "1",
                       "2" );

         FactHandle fa1 = (FactHandle) ksession.insert( a1 );
         FactHandle fa2 = (FactHandle) ksession.insert( a2 );
         FactHandle fa3 = (FactHandle) ksession.insert( a3 );

         // a2, a3 are blocked by a1
         // modify a1, so that a1,a3 are now blocked by a2
         a1.setField2( "1" ); // Do
         ksession.update( fa1,
                          a1 );
         a1.setField2( "2" ); // Undo
         ksession.update( fa1,
                          a1 );

         // modify a2, so that a1,a2 are now blocked by a3
         a2.setField2( "1" ); // Do
         ksession.update( fa2,
                          a2 );
         a2.setField2( "2" ); // Undo
         ksession.update( fa2,
                          a2 );

         // modify a3 to cycle, so that it goes on the memory end, but 
in a previous bug still blocked a1
         ksession.update( fa3,
                          a3 );

         a3.setField2( "1" ); // Do
         ksession.update( fa3,
                          a3 );
         ksession.fireAllRules();
         assertEquals( 1,
                       list.size() ); // a2 should still be blocked by 
a1, but bug from previous update hanging onto blocked

         ksession.dispose();
     }



More information about the rules-dev mailing list