Component testing

 

Component testing (also known as unit or module testing) searches for defects in and verifies the functioning of software modules, programs, objects, classes, etc. 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. Most often stubs and drivers are used to replace the missing software and simulate the interface between the software components in a simple manner. A stub is called from the software component to be tested; a driver calls a component to be tested.

 

Component testing may include testing of functionality (e.g., correctness of calculations) and specific nonfunctional characteristics such as resource-behavior (e.g. memory leaks), performance or robustness testing, as well as structural testing (e.g. decision coverage)

Test basis

• Detailed design
• Code
• Data model
• Component specifications

Test objects

• Components, units or modules
• Code and data structures
• Classes
• Database modules

Typical defects and failures

• Incorrect functionality (e.g., not as described in design specifications) 
• Data flow problems 
• Incorrect code and log
  

Specific approaches and responsibilities

Typically, component testing occurs with access to the code being tested and with the support of the development environment, such as a unit test framework or debugging tool, and in practice usually involves the programmer who wrote the code. Sometimes, depending on the applicable level of risk, component testing is carried out by a different programmer thereby introducing independence. Defects are typically fixed as soon as they are found, without formally recording the incidents found.

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.