[rules-dev] writing unit tests

[Leonardo Gomes]

I totally agree, except for the inline DRL :)

If it's a big enough DRL (let's say +3 rules), isn't it easier to have
something on the lines of the existing integration tests inside
drools-compiler? With the drl in the resources folder.

I know that people say "a test is not a unit test if it touches the
filesystem", but as long as Java doesn't support a proper way of inlining
XML </> (or DRL in this case, or different text formats in the general
case), like Scala does, I personally think it's easier and more readable to
have a separate file.

My 5 cents.

Leo.


On Tue, May 17, 2011 at 4:16 AM, Mark Proctor <mproctor at codehaus.org> wrote:

> 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();
>     }
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110517/8122c4e1/attachment.html