2.2.1. Component Testing

Objectives of component testing

Component testing (also known as unit or module testing) focuses on components that are separately testable.

Objectives of component testing include:

• Reducing risk

• Verifying whether the functional and non-functional behaviors of the component are as designed and specified

• Building confidence in the component’s quality

• Finding defects in the component

• Preventing defects from escaping to higher test levels

In some cases, especially in incremental and iterative development models (e.g., Agile) where code changes are ongoing, automated component regression tests play a key role in building confidence that changes have not broken existing components.

Component testing is often done in isolation from the rest of the system, depending on the software development lifecycle model and the system, which may require mock objects, service virtualization, harnesses, stubs, and drivers. Component testing may cover functionality (e.g., correctness of calculations), non-functional characteristics (e.g., searching for memory leaks), and structural properties (e.g., decision testing).

Test basis

Examples of work products that can be used as a test basis for component testing include:

• Detailed design

• Code

• Data model

• Component specifications

Test objects

Typical test objects for component testing include:

• Components, units or modules

• Code and data structures

• Classes

• Database modules

Typical defects and failures

Examples of typical defects and failures for component testing include:

• Incorrect functionality (e.g., not as described in design specifications)

• Data flow problems

• Incorrect code and logic

Defects are typically fixed as soon as they are found, often with no formal defect management. However, when developers do report defects, this provides important information for root cause analysis and process improvement.

Specific approaches and responsibilities

Component testing is usually performed by the developer who wrote the code, but it at least requires access to the code being tested. Developers may alternate component development with finding and fixing defects. Developers will often write and execute tests after having written the code for a component. However, in Agile development especially, writing automated component test cases may precede writing application code.

For example, consider test driven development (TDD). Test driven development is highly iterative and is based on cycles of developing automated test cases, then building and integrating small pieces of code, then executing the component tests, correcting any issues, and re-factoring the code. This process continues until the component has been completely built and all component tests are passing. Test driven development is an example of a test-first approach. While test driven development originated in eXtreme Programming (XP), it has spread to other forms of Agile and also to sequential lifecycles (see ISTQBCTFL- AT).