Software Testing Stubs and Drivers

Software modules rarely work alone. A checkout module calls a payment module, and the payment module calls a bank service. Testers often need to check one module before its neighbors exist. Stubs and drivers fill those gaps with simple stand-in code, so testing can proceed without waiting.

The Problem They Solve

Suppose developers finish the Order module on Monday, and the Payment module arrives two weeks later. Testing Order only after Payment is ready would delay the project. A stub imitates Payment so the team can test Order right away.

What Is a Stub

A stub is a small piece of code that replaces a lower-level module being called. The stub returns fixed answers and performs no real work.

Layman Example

A driving school trainee practices parking with a cardboard cone standing in for a real car. The cone has no engine, no doors, and no paint. The cone still gives the trainee something to park next to. A stub plays the same role.

Code Example

function paymentStub(amount) {
    // Always approves, regardless of the amount
    return { status: "APPROVED", transactionId: "TEST123" };
}

What Is a Driver

A driver is a small piece of code that calls the module under test. A driver acts in the place of a higher-level module that does not exist yet. The driver sends inputs and collects outputs.

Layman Example

A mechanic tests a new engine on a stand before the car body exists. The mechanic turns the key on the stand and watches the engine respond. The stand and the key act as the driver.

Code Example

function testDiscountModule() {
    var result = calculateDiscount(200, "SAVE10");
    console.log(result === 180 ? "PASS" : "FAIL");
}

How They Fit Together

  Top-down testing:                 Bottom-up testing:

  [Main Module]  (real)             [DRIVER]  (fake caller)
       |                                 |
  [Order Module] (under test)       [Payment Module] (under test)
       |                                 |
  [STUB: Payment] (fake)            [Bank Module] (real)

Integration Strategies

Top-Down Integration

Testers begin with the highest-level module and add lower modules step by step. Missing lower modules need stubs. The approach finds design flaws in the main flow early.

Bottom-Up Integration

Testers begin with the lowest-level modules and move upward. Missing upper modules need drivers. The approach checks the foundation modules first.

Sandwich Integration

Teams combine both directions and meet in the middle. The strategy suits large systems with many layers.

Stub vs Driver

Point	Stub	Driver
Role	Receives calls	Makes calls
Replaces	Lower-level module	Higher-level module
Used in	Top-down testing	Bottom-up testing
Returns	Canned data	Inputs and result checks

Related Idea: Mocks

Modern unit testing frameworks create mocks and fakes. A mock records how the code under test called it, so a test can check that the payment service received exactly one request. Many tools generate stubs and mocks automatically, which removes the need to write them by hand.

Benefits

• Teams test modules in parallel instead of in sequence.
• Testers isolate a failure to one module.
• Tests run fast because no real network or database call happens.
• Teams simulate rare conditions, such as a bank timeout, with ease.

Limitations

• A stub may behave differently from the real module and hide integration defects.
• Teams must maintain stubs when real interfaces change.

Replace stubs and drivers with real modules as soon as the real modules become available, and repeat the tests to confirm the true behavior.