I totally agree, except for the inline DRL :)<br><br>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.<br>
<br>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 <span id="goog_448678280"></span><a href="/">inlining XML<span id="goog_448678281"></span></a> (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.<br>
<br>My 5 cents.<br><br>Leo.<br><br><br><div class="gmail_quote">On Tue, May 17, 2011 at 4:16 AM, Mark Proctor <span dir="ltr"><<a href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
It's great when people attach unit tests to jiras, it would be ever<br>
better if they are just cut nad paste single files, rather than entire<br>
projects, which take more time for us to fiddle with. Also please do try<br>
and pair your actual program "main" examples down to minimal unit tests<br>
of the actual problem. If you suspect the problem is MVEL, then please<br>
do a minimal MVEL test, without Drools.<br>
<br>
Put static classes in the same file, put rules in a concatenated string.<br>
This means testing is as easy as cut and paste for us, and it can be<br>
easily added to existing test classes. For example, from MiscTest.<br>
<br>
<br>
public static class A {<br>
private String field1;<br>
private String field2;<br>
<br>
public A(String field1,<br>
String field2) {<br>
this.field1 = field1;<br>
this.field2 = field2;<br>
}<br>
<br>
public String getField1() {<br>
return field1;<br>
}<br>
<br>
public void setField1( String field1 ) {<br>
this.field1 = field1;<br>
}<br>
<br>
public String getField2() {<br>
return field2;<br>
}<br>
<br>
public void setField2( String field2 ) {<br>
this.field2 = field2;<br>
}<br>
<br>
public String toString() {<br>
return "A) " + field1 + ":" + field2;<br>
}<br>
}<br>
<br>
@Test<br>
public void testExistsIterativeModifyBug() {<br>
// JBRULES-2809<br>
// This bug occurs when a tuple is modified, the remove/add<br>
puts it onto the memory end<br>
// However before this was done it would attempt to find the<br>
next tuple, starting from itself<br>
// This meant it would just re-add itself as the blocker, but<br>
then be moved to end of the memory<br>
// If this tuple was then removed or changed, the blocked was<br>
unable to check previous tuples.<br>
<br>
String str = "";<br>
str += "package org.simple \n";<br>
str += "import " + A.class.getCanonicalName() + "\n";<br>
str += "global java.util.List list \n";<br>
str += "rule xxx \n";<br>
str += "when \n";<br>
str += " $f1 : A() \n";<br>
str += " exists A(this != $f1, eval(field2 ==<br>
$f1.getField2())) \n";<br>
str += " eval( !$f1.getField1().equals(\"1\") ) \n";<br>
str += "then \n";<br>
str += " list.add($f1); \n";<br>
str += "end \n";<br>
<br>
KnowledgeBase kbase = loadKnowledgeBaseFromString( str );<br>
<br>
StatefulKnowledgeSession ksession =<br>
kbase.newStatefulKnowledgeSession();<br>
List list = new ArrayList();<br>
ksession.setGlobal( "list",<br>
list );<br>
<br>
A a1 = new A( "2",<br>
"2" );<br>
A a2 = new A( "1",<br>
"2" );<br>
A a3 = new A( "1",<br>
"2" );<br>
<br>
FactHandle fa1 = (FactHandle) ksession.insert( a1 );<br>
FactHandle fa2 = (FactHandle) ksession.insert( a2 );<br>
FactHandle fa3 = (FactHandle) ksession.insert( a3 );<br>
<br>
// a2, a3 are blocked by a1<br>
// modify a1, so that a1,a3 are now blocked by a2<br>
a1.setField2( "1" ); // Do<br>
ksession.update( fa1,<br>
a1 );<br>
a1.setField2( "2" ); // Undo<br>
ksession.update( fa1,<br>
a1 );<br>
<br>
// modify a2, so that a1,a2 are now blocked by a3<br>
a2.setField2( "1" ); // Do<br>
ksession.update( fa2,<br>
a2 );<br>
a2.setField2( "2" ); // Undo<br>
ksession.update( fa2,<br>
a2 );<br>
<br>
// modify a3 to cycle, so that it goes on the memory end, but<br>
in a previous bug still blocked a1<br>
ksession.update( fa3,<br>
a3 );<br>
<br>
a3.setField2( "1" ); // Do<br>
ksession.update( fa3,<br>
a3 );<br>
ksession.fireAllRules();<br>
assertEquals( 1,<br>
list.size() ); // a2 should still be blocked by<br>
a1, but bug from previous update hanging onto blocked<br>
<br>
ksession.dispose();<br>
}<br>
<br>
_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
</blockquote></div><br>