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

Driver and Stub are doubles , also known as mocks component during software testing, whether automated or not.

If we talk about the level of automated testing implemented by the programmer himself, the explanation of the stub and other stunts can be seen here: What is the difference between mock and stub?

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

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

What's the difference between them?

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

Maybe you want to:

• test the two components working together;
• test the A component without depending on the operation of the B component (perhaps component B is not available when testing A);
• Or maybe it's the reverse: You need to test B but your A consumer is not available.

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

1) The A component is tested by consuming the actual B component, so the two components are tested in this scenario .
2) When testing the A component, the B dependency is replaced by a stuntman (a substitute component, used only during the tests). In this scenario only the A component is being tested.
3) The B component is being tested in isolation without its consumer, which has been replaced by a stunt double. In this scenario, only the B component is being tested.

Driver and Stub

In this example, the A component is the consumer, the orchestrator of the operation being tested. If I want to test it independently (or if I simply do not have the dependency still available), I replace this dependency with a Stub , which should give preprogrammed ready answers. >

Now, if the test focus is just the dependency, the B component, I replace the consumer with a Driver , which will try to simulate the component tested.

An example

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

And when you actually test the API, you replace the mobile application with software that simplifies and even automates Http requests. This other software would be the Driver stunt.

In which situations should they be used?

You can use them when testing a 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 do not we have Driver in unit testing

The Driver rating appears more in the QA universe.

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

Integration testing

Integration Test is the software test phase in which modules are combined and group tested. It follows the unit test, where the modules are individually tested, and precede the system test, where the complete (integrated) system is tested in an environment that simulates the production environment.

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

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

Top-down

As you can see from the name itself, using the Top-down technique, the test starts from the highest level to the lowest level, ie 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 stubs are replaced by the actual modules, one at a time.

Advantages

• Enables early verification of high-level behavior
• A single driver is required
• Modules can be added one at a time in each step, if desired
• Supports both breadth first and depth first approaches

Disadvantages

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

Bottom-up

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

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

Advantages

• Enables early checking for low-level behavior
• Stubs are not needed
• Easier to formulate input data for some sub-trees
• Easier to interpret output data for other sub-trees

Disadvantages

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

Reference:

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