What is the concept of Stubs and Drivers in integration tests?

Question

• What is the concept of driver and stubs in integration tests, what is the difference between them?

• In what situations should be used?

Answer 1

What is the concept of driver and stub in integration tests?

Driver and Stub are stuntmen (doubles, also known as mocks), whose function is to replace a component during automated or non-automatic software testing.

If we talk about the level of automated tests implemented by the programmer himself, the explanation of stub and other stuntmen can be seen here: What’s the difference between mock and stub?

But note that at this level of automation, where we use frameworks xUnit and we write the tests in the same language we use to write the production code, the Driver.

The kind of stuntman Driver is used in tests of "black box", which are tests performed not on the source code but against the external interfaces of the system, such as web forms or HTTP Apis.

What’s the difference between them?

Consider an architecture where a component To depends on the component B. Component B does nothing alone - it is only consumed by component A.

Maybe you want to:

• test the two components working together;
• test the component To without depending on the operation of the component B (Perhaps component B is not even available when testing A);
• or maybe it’s the other way around: you need to test the B but its consumer To is not available.

This leaves you with 3 possible test scenarios (image taken from Quora):

• 1) The component To is tested by consuming the component B real, so that the two components are tested in this scenario.

• 2) When testing the component To, dependence B is replaced by a double (a substitute component, used only during testing). In this scenario only the component To is being tested.

• 3) The component B is being tested alone without your consumer, who has been replaced by a double. In this scenario, only the component B is being tested.

Driver and Stub

In this example, the component To is the consumer, the orchestrator of the operation being tested. If I want to test it independently (or if I simply don’t have the dependency yet available), I replace this dependency with a Stub, which must provide pre-programmed ready responses.

Now, if the focus of the test is precisely dependence, the component B, I replace the consumer with a Driver, which will try to simulate the consumption of the tested component.

An example

To better assimilate this example, we can think of the component To as being a smartphone app and the component B as being a HTTP API consumed by this application.

So when you go to test the application, instead of consuming the actual API (for example a complex backend system) you create a stunt that replicates the API in question by providing ready-made answers. This API stunt would be a Stub.

And when you’re going to actually test the API, you replace the mobile app with software that simplifies and even automates HTTP requests. This other software would be the double of the type Driver.

In what situations should be used?

You can use them when testing one component when the other is not available (it is an external resource, has high complexity, has relevant cost to be consumed, is not yet ready, etc.) or even when it is available but you do not want your behavior to affect the test results of another component.

Why don’t we have Driver in the unit tests

The classification Driver appears more in the universe of QA (Quality Assurance).

It does not appear at the level of automated tests in style xUnit because, in an analogy, the Driver would be the unit test code itself, which doesn’t need a special name - it’s just the test code :-)

Answer 2

Integration test

Integration test is the phase of software testing in which modules are combined and tested in a group. It succeeds the unit test, in which the modules are tested individually, and precedes the system test, in which the complete (integrated) system is tested in an environment that simulates the production environment.

In the context of integration testing, we use the elements stubs and drivers

• Stubs are pseudo-implementations of certain specifications (basic/trivial/expected cases)
• Drivers are operations that automate testing according to test cases

Top-down

As can be seen by its name, using the Top-down technique, the test starts from the highest level to the lowest, that is, the highest level components are integrated first. The test uses driver and stubs:

• The driver is used as the main control module, and the actual modules are replaced by stubs
• As the tests are being performed the stubs are replaced by the actual modules, one at a time.

Perks

• Allows early verification of high-level behavior
• A single driver is required
• Modules can be added one at a time at each step if desired
• It supports both the first breadth' and first' approaches

Disadvantages

• Delays low level behavior checking
• Stubs are needed to supply elements still missing
• Test case entries can be difficult to formulate
• Test case outputs can be difficult to interpret
  • Oracles may be required to inspect expected results

Bottom-up

Integration is done from the most basic level of the hierarchy. Stubs are not always needed.

• Lower level modules are combined.
• For each combination a driver is created that coordinates the input and output of the test cases.
• The module is tested
• The driver is replaced by the corresponding module combination, which interacts with the top level modules

Perks

• Allows early verification of low-level behavior
• Stubs are not needed
• Easier to formulate input data for some subtrees
• Easier to interpret output data for other sub-trees

Disadvantages

• Slows down high-level behavior checking
• Drivers are required for elements not yet implemented
• As sub-trees are combined, a large number of elements must be integrated at once

Reference:

• Software Engineering Books - 9th Edition 2011 - Ian Sommerville