OpenUP/abrd_openup/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.5/uma.ecore"
    xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-7v9Ia3BxJdgAGS6Kol2L3w"
    name="develop_unit_tests,_ioCPkDzEEdyA6a_I80swHw" guid="-7v9Ia3BxJdgAGS6Kol2L3w"
    changeDate="2007-08-23T12:59:51.718-0700">
  <mainDescription>&lt;a id=&quot;XE_unit_tests__develop&quot; name=&quot;XE_unit_tests__develop&quot;>&lt;/a> &#xD;
&lt;p class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0cm&quot;>&#xD;
    Rule Unit Testing is the process of testing a specific rule in the context of the rule set in which it is deployed.&#xD;
    Rule Unit Testing allows rule writers to:&#xD;
&lt;/p>&#xD;
&lt;ul style=&quot;MARGIN-TOP: 0cm&quot; type=&quot;disc&quot;>&#xD;
    &lt;li class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0cm; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt&quot;>&#xD;
        Validate each rule in the context of its rule set&#xD;
    &lt;/li>&#xD;
    &lt;li class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0cm; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt&quot;>&#xD;
        Control the rule set quality&#xD;
    &lt;/li>&#xD;
    &lt;li class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0cm; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt&quot;>&#xD;
        Conduct some impact analysis when rules are in conflict&#xD;
    &lt;/li>&#xD;
    &lt;li class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0cm; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt&quot;>&#xD;
        Helps to have non-regression tests&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0cm&quot;>&#xD;
    &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&#xD;
    design may not put a rule in the agenda if the conditions are not matched. This means that when the rule writer write a&#xD;
    new rule, even if the data are sent to trigger the execution of this new rule it is possible that a rule fired before&#xD;
    the new one, with change the condition of the data so that this new rule will never be eligible. Developing a complete&#xD;
    set of unit test is an efficient way to see this problem, and to improve the rule set design. Some powerful BRMS&#xD;
    platform has rules consistency checking which helps to do some static analysis of those potential conflict by analyzing&#xD;
    the conditions and the actions of the rules. For sure real test cases will complete the picture.&lt;/span>&#xD;
&lt;/p>&lt;br class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0cm&quot; />&#xD;
&lt;br />&#xD;
&lt;span&#xD;
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&#xD;
a Test Driven Development approach rule writer can develop the test script preparing the data to trigger each rule,&#xD;
depending of the BRMS platform used, the script generation can be done automatically or not. What is important is develop&#xD;
reusable test case organized in test suite which include assertion statement to validate the expected results. This is&#xD;
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; />&#xD;
&lt;br /></purpose>
</org.eclipse.epf.uma:TaskDescription>