| <?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="-UW-yTFk3AppqcGGU-Px63A" |
| name=",_znlIcJR9EdyVKbgqUOtqQA" guid="-UW-yTFk3AppqcGGU-Px63A" changeDate="2008-02-01T10:24:00.703-0800" |
| version="7.2.0"> |
| <mainDescription><p>
 |
| Developer testing is different from other forms of testing in that it is based on the expected behavior of code units
 |
| rather than being directly based on the system requirements.
 |
| </p>
 |
| <p>
 |
| It is best to do this at a small scale, much smaller than the complete code base to be authored by a developer over the
 |
| course of an iteration. This can be done for one operation, one field added to a user interface, one stored procedure,
 |
| etc. As the code base is incrementally built, new tests will be authored and existing tests might be revisited to test
 |
| additional behavior.
 |
| </p></mainDescription> |
| <keyConsiderations><ol>
 |
| <li>
 |
| Automate tests via a unit regression testing tool (for example, xUnit) so that tests may be run by developers
 |
| whenever they make changes to the code.
 |
| </li>
 |
| <li>
 |
| Test to the risk of the implementation element. For example, the more critical an element is, the more important it
 |
| is to test it thoroughly.
 |
| </li>
 |
| <li>
 |
| Pair with&nbsp;team members with testing skills&nbsp;in all steps of this task to gain insight on testing and
 |
| quality considerations.
 |
| </li>
 |
| </ol>
 |
| <p>
 |
| The&nbsp;<a class="elementLink" href="./../../core.mgmt.slot.base/workproducts/project_work_slot_F12BAC46.html" guid="_1QZI8EfUEdyiPI8btkmvmw">[Project Work]</a> is implicitly used in implementation tasks to manage which requirements
 |
| or change requests are being realized in the code.
 |
| </p></keyConsiderations> |
| <sections xmi:id="_C_j_EJR-EdyVKbgqUOtqQA" name="Refine scope and identify the test(s)" |
| guid="_C_j_EJR-EdyVKbgqUOtqQA"> |
| <sectionDescription><p>
 |
| Select the increment of work to be tested and identify developer test(s)&nbsp;to verify that the software
 |
| implementation&nbsp;being developed behaves correctly. One source for the expected behavior for an implementation
 |
| element is the software design.
 |
| </p>
 |
| <p>
 |
| In identifying the&nbsp;tests or in any other part of this task, consider collaborating with a team member who is
 |
| well-versed in the issues of testing.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_Es64wJR-EdyVKbgqUOtqQA" name="Write the test setup" guid="_Es64wJR-EdyVKbgqUOtqQA"> |
| <sectionDescription>To successfully run a test the system must be in a known state so that the correct behavior can be defined. Implement the
 |
| setup logic that must be performed as part of the developer test.</sectionDescription> |
| </sections> |
| <sections xmi:id="_Fm4moJR-EdyVKbgqUOtqQA" name="Define the expected results" guid="_Fm4moJR-EdyVKbgqUOtqQA"> |
| <sectionDescription><p>
 |
| Define the expected results of each test so that it can be verified.
 |
| </p>
 |
| <p>
 |
| After a test runs, you need to be able to compare the results of running the test against what was expected to happen.
 |
| The test is successful when the actual results match the expected results.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_GZaPwJR-EdyVKbgqUOtqQA" name="Write the test logic" guid="_GZaPwJR-EdyVKbgqUOtqQA"> |
| <sectionDescription>Write the steps that perform the actual test(s).</sectionDescription> |
| </sections> |
| <sections xmi:id="_IMxq0JR-EdyVKbgqUOtqQA" name="Define the test response" guid="_IMxq0JR-EdyVKbgqUOtqQA"> |
| <sectionDescription>Define the information the test(s) must produce to successfully indicate success or failure. Consider if a response of True
 |
| or False is sufficient, or if a detailed message should be logged as well.</sectionDescription> |
| </sections> |
| <sections xmi:id="_JAiqEJR-EdyVKbgqUOtqQA" name="Write clean-up code" guid="_JAiqEJR-EdyVKbgqUOtqQA"> |
| <sectionDescription>Identify, and then implement, the steps to be followed in order to restore the environment to the original state for each
 |
| test. The goal is to ensure that there are no side effects from running the tests.</sectionDescription> |
| </sections> |
| <sections xmi:id="_KkDrQJR-EdyVKbgqUOtqQA" name="Test the test" guid="_KkDrQJR-EdyVKbgqUOtqQA"> |
| <sectionDescription><p>
 |
| Verify that each developer test works correctly. To do this:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Run the test(s), observe their behavior, and fix any defects in the tests.
 |
| </li>
 |
| <li>
 |
| Ensure that the expected results are defined properly and that they're being checked correctly.
 |
| </li>
 |
| <li>
 |
| Check the clean-up logic for each test.
 |
| </li>
 |
| <li>
 |
| Ensure that each developer test works within your test suite framework.
 |
| </li>
 |
| </ul></sectionDescription> |
| </sections> |
| <purpose>Prepare to validate an implementation element (e.g. an operation, a class, a stored procedure) through unit testing. The
 |
| result is one or more new developer tests.</purpose> |
| <alternatives>Rely on acceptance tests to validate your software. This will likely be time consuming, late, and not as effective as
 |
| developer testing in identifying bugs and finding their location in the code.</alternatives> |
| </org.eclipse.epf.uma:TaskDescription> |
