epf_prac_151/practice.tech.abrd.base/tasks/develop_unit_tests.xmi

<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-7v9Ia3BxJdgAGS6Kol2L3w" name="develop_unit_tests,_ioCPkDzEEdyA6a_I80swHw" guid="-7v9Ia3BxJdgAGS6Kol2L3w" changeDate="2007-08-23T00:59:51.000-0700" version="7.5.1">
  <mainDescription>&lt;a id=&quot;XE_unit_tests__develop&quot; name=&quot;XE_unit_tests__develop&quot;>&lt;/a> 
&lt;p class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0cm&quot;>
    Rule Unit Testing is the process of testing a specific rule in the context of the rule set in which it is deployed.
    Rule Unit Testing allows rule writers to:
&lt;/p>
&lt;ul style=&quot;MARGIN-TOP: 0cm&quot; type=&quot;disc&quot;>
    &lt;li class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0cm; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt&quot;>
        Validate each rule in the context of its rule set
    &lt;/li>
    &lt;li class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0cm; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt&quot;>
        Control the rule set quality
    &lt;/li>
    &lt;li class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0cm; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt&quot;>
        Conduct some impact analysis when rules are in conflict
    &lt;/li>
    &lt;li class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0cm; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt&quot;>
        Helps to have non-regression tests
    &lt;/li>
&lt;/ul>
&lt;p class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0cm&quot;>
    &lt;span style=&quot;mso-bidi-language: HE&quot;>There is a major difference between testing a code, and a rule. A rule engine per
    design may not put a rule in the agenda if the conditions are not matched. This means that when the rule writer write a
    new rule, even if the data are sent to trigger the execution of this new rule it is possible that a rule fired before
    the new one, with change the condition of the data so that this new rule will never be eligible. Developing a complete
    set of unit test is an efficient way to see this problem, and to improve the rule set design. Some powerful BRMS
    platform has rules consistency checking which helps to do some static analysis of those potential conflict by analyzing
    the conditions and the actions of the rules. For sure real test cases will complete the picture.&lt;/span>
&lt;/p>&lt;br class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0cm&quot; />
&lt;br />
&lt;span
style=&quot;FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-language: HE; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US&quot;>Using
a Test Driven Development approach rule writer can develop the test script preparing the data to trigger each rule,
depending of the BRMS platform used, the script generation can be done automatically or not. What is important is develop
reusable test case organized in test suite which include assertion statement to validate the expected results. This is
efficient tool to put in place automatic non regression tests.&lt;/span></mainDescription>
  <purpose>&lt;br class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0cm&quot; />
&lt;br /></purpose>
</org.eclipse.epf.uma:TaskDescription>