| <?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><p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| The tests should be self-documenting in a way that makes it clear upon completion of the test whether the component has
 |
| run correctly.
 |
| </p></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><p>
 |
| There is no predefined template for this&nbsp;work product and a testing tool will&nbsp;affect how the work product is
 |
| handled, but here are some key issues that should be addressed:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Setup
 |
| </li>
 |
| <li>
 |
| Inputs
 |
| </li>
 |
| <li>
 |
| Script
 |
| </li>
 |
| <li>
 |
| Expected Results
 |
| </li>
 |
| <li>
 |
| Evaluation Criteria
 |
| </li>
 |
| <li>
 |
| Clean-Up
 |
| </li>
 |
| </ul></briefOutline> |
| <representationOptions><p align="left">
 |
| The following are recommendation and options for representing this work product.
 |
| </p>
 |
| <h4>
 |
| Recommendation: Automated Code Unit
 |
| </h4>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| When code is the&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.
 |
| </p>
 |
| <h4>
 |
| Option: Manual Instructions
 |
| </h4>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <h4>
 |
| Option: Embedded Code
 |
| </h4>
 |
| <p>
 |
| Certain technologies (such as Java&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.
 |
| </p></representationOptions> |
| </org.eclipse.epf.uma:ArtifactDescription> |