| <?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><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> |