[rules-dev] writing unit tests
Mark Proctor
mproctor at codehaus.org
Tue May 17 11:00:09 EDT 2011
On 17/05/2011 08:44, Leonardo Gomes wrote:
> 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.
Once the rule(s) gets larger yes. The problem we have now though is look
at the integration tests resource folder, it gets big pretty quick. And
ofcourse there is no automatic button to go from the java test to the
drl test file, so it's extra key presses. When you are doing a lot of
reviewing, or checking old regressions, it can can be nice to have
everything in a single place. Personally I just wish Java had multi-line
strings and then this wouldn't be an issue :(
>
> 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.
It's nothign to do with being a proper unit test, and more just making
edson and my life easier.
Mark
>
> My 5 cents.
>
> Leo.
>
>
> On Tue, May 17, 2011 at 4:16 AM, Mark Proctor <mproctor at codehaus.org
> <mailto: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 <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> 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/54ba04cf/attachment-0001.html
More information about the rules-dev
mailing list