What is the difference between mock & stub?
- in what situations should it be used?
- What is the difference between them?
2 answers
What is the difference between mock and stub?
While a stub only provides ready answers to the calls that will be made during the Test, mock goes further and, in addition to providing the answers, also validates the calls - it knows the expected behavior of the system and tests this behavior.
Thus, when replacing a component during testing, a stub would have the following responsibility:
- If the test invokes method a, return B.
- If the test invokes method X, return Y.
While a mock would have the following responsibility:
- the test should invoke method a first, passing the value 1 as parameter, hence return B.
- the test should then invoke method X, passing the value 2 as parameter, hence return Y.
- if the test does not exactly follow this sequence, it fails.
So we can put in the list of differences the fact that a mock is more complex than a stub.
It is common for developers to use mock frameworks (Jmock, EasyMock, Mockito, ...) only as stubs (do not validate the interaction between the tests and the "mockedup"component). In this case the framework is specialized in mocks, but conceptually a stub is being used and not a mock.
It is also not uncommon for developers to call "mock" all kinds of stunts. And there is nothing so wrong in this since from the heart you know the differences and complexity brought by each type.
In what situations is using one more advantageous than using the other?
Established that both serve to replace real components (they are "stuntmen" of these components) during testing, and understood the difference between them, it becomes clear when to use one and when to use another:
-
Use
stubto test whether a code, given a certain input (ready responses of stub methods), produces certain output. -
Use
mockto test whether a code behaves the way you expect when it comes to interactions with the component that mock is replacing.
Another stuntman in the story:
Sometimes, in addition to providing ready answers, we want to know if the test actually invoked a method of the substituted component, or even how many times it invoked, but we don't need to be so rigid as to check the sequence of calls or the value of the parameters, in this case we put some simple state in stub (call Counter of the method, for example) and thus get a spy - another type of stunt that is between stub and mock, with some benefits of the second and almost all the simplicity of the first.
Concluding:
We use the different types of stuntmen according to the need of our tests, and we give preference to the less types complex because they are less coupled to the production code, clearer to understand, easier to receive maintenance.
A list of stuntmen in ascending order of complexity would be:
-
1st
Dummy -
2nd
Fake- Fake can be quite complex (like an in-memory database or an embedded application server) but it is not coupled to your production code so it is considered low complexity. -
3rd
Stub -
4th
Spy -
5º
Mock
The way to be able to use stuntmen in small quantities or use those of lower complexity is the constant attention to the design of the system.
I think the canonical reference on the subject is the article by Martin Fowler. It shows the difference between 4 types of substitutes:
Dummy
Are objects used to populate a parameter list when what it contains in them is not relevant. This Objects will not be used in fact.
Fake
Are objects with real implementations but that do not do exactly what is expected in a production environment.
Stubs
Are objects created for facilitate testing by giving pre-determined answers and doing operations that provide additional information of the use of the method under test. It is more important to make it easier for the test to happen with peace of mind than to run the test, so much so that it does not have the function of making the test fail. Used for replace states.
Mocks
Are objects with implementations specifying as a method is expected to be used in real code. It is with them that you replaces behaviors .
Conclusion
The choices depend a bit on the style as you do your tests. I know a lot of people won't like this answer but even though I like the right things, I find it all too exaggerated for most projects. I'm not undoing the tools but this often seems NoSQL. It gives a lot to talk about but few really need it all. Only reinforcement that think well in your architecture and test your implementation is critical.