Task: Implement Unit Tests
Implement tests for an entire component so it can be validated prior to integration.
Disciplines: Development
Purpose
  • To implement one or more tests that validate a component
  • To develop tests that can be executed in conjunction with other tests as part of a larger test infrastructure
Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    Optional:
      Outputs
        Process Usage
        Main Description

        Unit testing is a brand of developer testing that performs black-box tests on implementation components after they've been implemented and white-box tested. The goal is to assure that a component functions correctly before it's integrated into the rest of the system.

        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. Use the demands of the design and the existing implementation to understand what needs to be tested.

        Members of the integration testing team can provide insight and direction during this task so robust and reusable tests are written. Testers often have a stake in the quality of unit tests as they're often re-used during integration testing.

        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, e.g. 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 ( e.g. 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.

        More Information