Work Product Descriptor: Developer Test |
The instructions that validate individual software components perform as specified.
Based on Method Work Product: Developer Test
Purpose
Evaluate that a software component performs as specified.
Relationships
Roles | Responsible: Developer | Modified By:
Input To | Mandatory: Run Developer Tests | Optional: None | External: None
Output From | Implement Developer Tests
Description
Brief Outline | There is no predefined template for this work product and a testing tool will affect how the work product is handled, but here are some key issues that should be addressed: Setup Inputs Script Expected Results Evaluation Criteria Clean-Up
Main Description | 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. The tests should be self-documenting in a way that makes it clear upon completion of the test whether the component has run correctly.
Properties
Optional |
Planned |
Tailoring
Impact of not having | 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.
Reasons for not needing | 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.
Representation Options | The following are recommendation and options for representing this work product. #### Recommendation: Automated Code Unit 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. When code is the 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. #### Option: Manual Instructions 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. #### Option: Embedded Code Certain technologies (such as Java™ 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.
More Information
Concepts | Test-first Design
Guidelines | Types of Developer Tests
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. View copyright information here: OpenUP Copyright