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