OpenUP/OpenUP_PT/library/openup_basic/workproducts/developer_test.xmi

<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" epf:version="1.0.0" xmi:id="_NqSB0qeqEdmKDbQuyzCoqQ" name="developer_test,_0YuXEclgEdmt3adZL5Dmdw" guid="_NqSB0qeqEdmKDbQuyzCoqQ" changeDate="2006-12-21T12:11:53.042-0500" version="1.0.0">
  <mainDescription>&lt;p&gt; This artifact covers all of 
  the steps that are required to validate 
  a software component. It specifies test entries, 
  execution conditions, and expected results. These details 
  are identified for the purpose of evaluating a 
  particular aspect of a scenario. &lt;/p&gt;
&lt;p&gt; The tests should be self-documenting in a way that 
  makes it clear upon completion of the test whether the component has 
  run correctly. &lt;/p&gt;</mainDescription>
  <purpose>Evaluate that a software component performs as specified.</purpose>
  <impactOfNotHaving>Not having developer tests can inhibit iterative development, because 
there is no assurance that modified components are still working correctly 
when you modify  components iteration by iteration.</impactOfNotHaving>
  <reasonsForNotNeeding>If the tests can be embedded into the actual production code, you might not need a separate work product. Nonetheless, some
level of support for developer testing is always necessary.</reasonsForNotNeeding>
  <briefOutline>&lt;p&gt;
    There is no predefined template for this&amp;nbsp;work product and a testing tool will&amp;nbsp;affect how the work product is
    handled, but here are some key issues that should be addressed:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        Setup
    &lt;/li&gt;
    &lt;li&gt;
        Inputs
    &lt;/li&gt;
    &lt;li&gt;
        Script
    &lt;/li&gt;
    &lt;li&gt;
        Expected Results
    &lt;/li&gt;
    &lt;li&gt;
        Evaluation Criteria
    &lt;/li&gt;
    &lt;li&gt;
        Clean-Up
    &lt;/li&gt;
&lt;/ul&gt;</briefOutline>
  <representationOptions>&lt;p align=&quot;left&quot;&gt;
    The following are recommendation and options for representing this work product.
&lt;/p&gt;
&lt;h4&gt;
    Recommendation: Automated Code Unit
&lt;/h4&gt;
&lt;p&gt;
    The most appropriate technique for running these tests is using code that tests the components fully and that you can
    run regularly as you update the system during development.
&lt;/p&gt;
&lt;p&gt;
    When code is the&amp;nbsp;sole form of the tests, you must take care to ensure that the code is self-documenting, including
    specifications of what conditions you are testing and what setup or clean-up is required for the test to run properly.
&lt;/p&gt;
&lt;h4&gt;
    Option: Manual Instructions
&lt;/h4&gt;
&lt;p&gt;
    In some cases, manual instructions can suffice. For example, when testing a user interface, a Developer could walk
    through a script, explaining the component. In this case, it can still be valuable to create a test harness that goes
    straight to the user interface. That way, the Developer can follow the script without having to walk through a
    complicated set of instructions to get to a particular screen or page.
&lt;/p&gt;
&lt;h4&gt;
    Option: Embedded Code
&lt;/h4&gt;
&lt;p&gt;
    Certain technologies (such as Java&amp;trade; 5 Test Annotation) enable you to embed tests in the implementation. In those cases,
    there will be a logical work product, but it will be assimilated into the code that you are testing. Here, too, take
    into consideration that you must ensure that the code is self-documenting.
&lt;/p&gt;</representationOptions>
</org.eclipse.epf.uma:ArtifactDescription>