Task Descriptor: Implement Unit Tests |
Implement tests for an entire component so it can be validated prior to integration.
Based on Method Task: Implement Unit Tests
Relationships
Roles | Primary: Developer | Additional: Tester | Assisting:
Inputs | Mandatory: Implementation | Optional: [Technical Design] | External: None
Outputs | Developer Test
Steps
Refine the scope and identify the tests
Select a single implementation component and identify appropriate tests that will verify all aspects of the externally observable behavior of the component. Define the following in each developer test: Goal: subsystem/component interface validation, implementation validation, reproduce a defect. Scope: subsystem, component, group of components (a single test should focus on a group of components only if they provide the same function). Test details: pre-conditions, post-conditions, set-up requirements (environment), invariants, input/output and execution conditions, observation/control points, clean-up actions.
Select the appropriate testing approach
Choose an automated testing approach whenever possible. In some cases, for example, usability testing, it may be necessary to test manually by following a sequence of instructions that have been documented in the developer test. Define what kind of test will be implemented and document it in the developer test. Possible options are: Programmed tests, using either the same software programming techniques and environment as the component under test, or less complex programming languages and tools ( for example, scripting languages, tcl, shell based, etc). Recorded or captured tests, built by using test automation tools which capture the interactions between the component under test and the rest of the system, and produce the basic tests Generated tests: some aspects of the test, either procedural or the test data, could be automatically generated using more complex test automation tools
Implement the test
Implement all the elements defined previously. Describe each developer test fully, whether it's automated or manual, so someone else can execute the test without supervision. Assure any manual tests include all the steps necessary to complete the test. Detail the test environment pre-conditions and what are the steps to get the component under test to the state where the tests can be executed successfully. Identify the clean-up steps to be followed in order to restore the environment to the original state. Pay special attention to the implementation of the observation/control points, as these might need special support that has to be implemented in the component under test. Leverage the design and the existing implementation to understand what's expected of the component from a black-box perspective.
Establish external data sets
In most of the cases, decoupling the test data from the developer test leads to a more maintainable solution. If the test's life span is short, hardcoding the data within the test might be more efficient. If many test execution cycles will be needed using different data sets, it's more efficient to store them externally. The advantages of decouple the test data from the developer test are: More than one test could use the same data set. Easy to modify and reuse the test data. Test data could be used to control the conditional branching logic within the test.
Verify the test implementation
Test the developer test. Check the environment setup and clean-up instructions. Run the test, observe its behavior and fix the test's defects. If the test will be long-lived, ask a person with less inside knowledge to run it and check if there is enough support information. Review it with other people within the development team and other interested parties.
Maintain traceability relationships as needed
Depending on the level of formality, you may need to maintain traceability relationships between the tests and the components. Document traces in the developer test or an automated tool.
Properties
Multiple Occurrences |
Event Driven |
Ongoing |
Optional |
Planned |
Repeatable |