Top Down Approach in Software Engineering

Stubs (also called called-programs) are temporary code pieces used during testing to simulate the behaviour of lower-level modules that are not yet implemented or integrated.

Stubs accept calls from the top-level module and return fixed or simulated responses so that the upper-level logic can be tested.

Common stub types include:

• Trace stubs — display trace/log messages for calls received.
• Parameter-display stubs — show values of parameters passed to the stub.
• Constant-return stubs — return predetermined values used by the caller.
• Behaviour-driven stubs — return values based on input parameters to mimic realistic responses.

• Fault localisation is easier for top-level behaviour because critical modules are tested early.
• Early prototypes of the system's top-level functionality can be obtained quickly.
• Major design flaws can be discovered and corrected early in the integration process.
• Requires fewer or no driver programs (since stubs simulate lower modules).
• Integration testing is performed in an environment similar to production as lower modules are gradually replaced with real implementations.
• Test case representation remains straightforward once I/O interfaces are defined for modules.

• Requires many stubs which adds development and maintenance overhead during testing.
• Lower-level modules get tested later and may be inadequately exercised early on.
• Testing some upper-level modules may be difficult until their dependencies are simulated correctly.
• Developing realistic stubs can incur additional cost and effort.
• The system's low-level behaviour and performance characteristics are validated late in the cycle.