What is Stubs and Drivers?

Stubs and drivers are temporary scaffolding programs used in integration testing to stand in for modules that are not yet built: a stub simulates a module that is called by the code under test, while a driver simulates a module that calls the code under test.

Start a Free Mock Interview

Free to start · 7-day trial on paid plans

IN DEPTH

In depth.

During incremental integration you often need to test a module before all the modules it connects to exist. Stubs and drivers fill those gaps. A stub is a dummy implementation of a lower-level, called module: it returns canned responses so the higher module can be exercised. A driver is a dummy higher-level, calling module: it invokes the lower module with test inputs so it can be exercised in isolation.

The direction of the dependency determines which you need. In top-down integration you build from the top, so the lower modules are missing, you use stubs. In bottom-up integration you build from the bottom, so the higher modules are missing, you use drivers. Sandwich integration uses both.

Stubs and drivers overlap with the broader idea of test doubles, but the terms are most associated with integration testing scaffolding rather than unit-level mocking. A simple memory aid: a stub stands in below the module under test (it is called), and a driver drives the module from above (it calls).

WHY IT MATTERS

Why interviewers ask about this.

The stub-vs-driver distinction is a frequently asked integration-testing question. Getting the direction right, stub is called, driver calls, and linking each to top-down vs bottom-up integration, demonstrates precise understanding rather than vague familiarity.

EXAMPLE

Example scenario.

To test a payment module before the shipping module it calls exists, the team writes a stub for shipping that returns a canned "shipping scheduled" response. Separately, to test a low-level discount module before the cart that calls it is ready, they write a driver that feeds the discount module test inputs and checks its outputs.

TIP

Interview tip.

Define a stub as a stand-in for a called (lower) module and a driver as a stand-in for a calling (higher) module. Tie them to integration style: top-down uses stubs (lower modules missing), bottom-up uses drivers (higher modules missing). The memory aid "stub is called, driver calls" prevents mix-ups.

FAQ

Frequently asked questions.

What is the difference between a stub and a driver?

A stub stands in for a module that is called by the code under test (a lower-level module), returning canned responses. A driver stands in for a module that calls the code under test (a higher-level module), invoking it with test inputs. Stub is called; driver calls.

When do you use stubs versus drivers?

In top-down integration you build top modules first, so lower called modules are missing, you use stubs. In bottom-up integration you build bottom modules first, so higher calling modules are missing, you use drivers. Sandwich (hybrid) integration uses both at once.