What are stubs and drivers in integration testing and when and how are they used?I know it comes under top down and bottom up approach respectively but I would like to have a real technology scenario for understanding it more clearly.
Driver A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system. [ISTQB]
Stub A skeletal or special-purpose implementation of a software component, used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component. [IEEE]
Others have given excellent definitions. I will try to give an example then.
Imagine you have an online shop. The shop has at least two tiers: frontend (GUI) and backend.
You may want to control and verify behaviour of the system on two levels: frontend or backend. On a frontend level you would replace an end-user with a driver that would send requests to the shop Web site. Possible technology would be WebDriver (previously called Selenium), which makes me even clearer why they called this technology this way. On the backend level you would replace frontend with another driver that would call backend services directly. For instance, if your backend exposes REST API, the driver would be some REST client, for instance Jersey or Apache HTTP client in Java world.
We haven't discussed a stub yet. Imagine the shop relies on some third part services responsible for credit card transactions, e.g., MasterCard or PayPal. It would be quite expensive to perform all of the tests with their services involved. Therefore, you can replace PayPal service with a stub, i.e, mock it. If PayPal service exposes SOAP interface, a possible implementation would be to create a fake SOAP Web service that could handle requests coming from the shop backend and respond with fake responses.
Note, for the above illustration I treated a mock and a stub patterns as same thing, neglecting a slight difference between them. The difference is about whether responses of a stub/mock are hardcoded (stub?) and predetermined or rather configurable within your test (mock?). I never remember which is for mock and which for stub. And I really don't care much as there are situations where both approaches can be mixed together, e.g., you may record some of stub/mock requests and responses (e.g., hardcoded SOAP messages), but make configurable only part of them, e.g., transaction balance number.
They talk about dummy values being passed to satisfy API requirements, stubs that replace real objects but returns hard coded values and smarter objects like mocks and spies.
Martin Fowler has excellent summary of Test Doubles terminology:
- Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
- Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryTestDatabase is a good example).
- Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test.
- Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
- Mocks are pre-programmed with expectations which form a specification of the calls they are expected to receive. They can throw an exception if they receive a call they don't expect and are checked during verification to ensure they got all the calls they were expecting.