What is a "Stub"?
I faced the question recently and recognised that this comparison between Stub and Driver is really clear and helpful:
Basically, stubs and drivers are routines that don’t actually do anything except declare themselves and the parameters they accept. The rest of the code can then take these parameters and use them as inputs.
+---------+-------------------------------+-------------------------------+ | | Stub | Driver | +---------+-------------------------------+-------------------------------+ | Type | Dummy codes | Dummy codes | +---------+-------------------------------+-------------------------------+ | Used in | Top Down Integration | Bottom Up Integration | +---------+-------------------------------+-------------------------------+ | Purpose | To allow testing of the upper | To allow testing of the lower | | | levels of the code, when the | levels of the code, when the | | | lower levels of the code are | upper levels of the code are | | | not yet developed. | not yet developed. | +---------+-------------------------------+-------------------------------+ | Example | A and B are components. | A and B are components. | | | A ---> B | A ---> B | | | | | | | A has been developed. | A still needs to be developed.| | | B still needs to be developed.| B has been developed. | | | Therefore, stub is used | Therefore, driver is used | | | in place of B to imitate it. | in place of A to imitate it | | | | | | | A ---> Stub | Driver ---> B | +---------+-------------------------------+-------------------------------+
From Difference between Stub and Driver
A "stub" is an implementation of an interface that exists to provide data/a response of some sort. For example:
- a DataSet
- list of Users
- an Xml File
Normally this would be provided by another service (be it Web Service, another application, a database) but in order to improve the testability of the code, the results are "faked".
A major benefit of this is that it allows assertions to be made in unit tests based on the data expected. If errors arise due to data errors, then tests can easily be added, a new stub created (replicating the data error) and code produced to correct the error.
Stubs differ to Mocks in that they are used to represent and test the state of an object, whereas a Mock tests its interaction.
Martin Fowler wrote an excellent article on this subject. From that article:
Meszaros uses the term Test Double as the generic term for any kind of pretend object used in place of a real object for testing purposes. The name comes from the notion of a Stunt Double in movies. (One of his aims was to avoid using any name that was already widely used.) Meszaros then defined four particular kinds of double:
- 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 in memory database 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. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.
- Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.
To put it in my own words: mock objects "expect" certain methods to be called on them, and typically cause a unit test to fail if their expectations aren't met. Stub objects provide canned responses (and can be autogenerated by helper libraries), but typically do not directly cause the unit test to fail. They are typically just used so that the object you're testing gets the data it needs to do its work.