Component testing, also known as unit, module, structure, code, or program testing, focuses on components that are separately testable without integrating with other components. For Example, for any application, Login, Registration, and Forgot Password are three separate components.
Component testing is often performed by the developer who wrote the code, or peer review is done. Developers may alternate component development with finding and fixing defects. Defects are typically fixed as soon as they are found, often with no formal defect management. However, when developers report defects, this provides essential information for root cause analysis and process improvement.
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 is performed on the Developer's Local Machine or Development Environment using debugging tools.
Objectives
Typical objectives of component testing include:
- Verifying whether the functional and non-functional behaviors of the component are as designed and specified. Component testing may cover functionality (e.g., the correctness of calculations), non-functional characteristics (e.g., searching for memory leaks), and structural properties (e.g., decision testing).
- Finding defects in the component
- Reducing Risk by finding defects early
- Building confidence in the component's quality by identifying as many defects as possible
- Preventing defects from escaping to higher test levels
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 or Interface
- 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
Specific Approaches and Responsibilities
Often Unit testing is performed after writing the code. However, in Agile Development, writing automated component test cases may precede writing application code. Test Driven Development (TDD) which originated in eXtreme Programming (XP), is an example of a test-first approach. Test-driven development is highly iterative and is based on cycles consisting of five steps:
- Developing automated test cases
- Executing the Test. The new test should fail for the expected reasons.
- Building and integrating small pieces of code
- Executing the component tests. All tests should now pass.
- Correcting any issues and Code Refactoring
Component Testing Techniques
There are two techniques of Component Testing −
- CTIS (Component Testing in Small): Component testing can be executed with or without separating the software components. When the testing is performed by isolating other components, it is known as CTIS.
- CTIL (Component Testing in Large): Component testing without separating the software components is known as component testing in large.