The Role of Mocks and Interfaces in TDD
Mocks and interfaces are crucial elements in TDD as they allow developers to write tests for code that has not yet been implemented. Mocks are objects that mimic the behaviour of real objects and are used to test the interactions between objects. Interfaces, on the other hand, define a set of methods that a class must implement, a contract that each class implementing that interface has to respect. By using interfaces, developers can create code that is flexible and easy to maintain.
NB: in the test doubles context, there is a naming problem - there is no common standard. I typically refer to Martin Fowler's naming, where Test Double is the general category where mocks, stubs and spies fall into. In this blog post, for simplicity, I will often use mocks to refer to them all, since it’s the most common word used.
The Pros and Cons of Using Mocks and Interfaces in TDD
The benefits of using mocks and interfaces in TDD are multiple:
- They allow developers to test their code in isolation, making it easier to identify and fix bugs.
- They also make it easier for developers to work in teams, as they make it easier to develop in smaller steps and have deployable code.
- Additionally, using interfaces makes code more modular and reusable, as different implementations can be swapped in and out without affecting the rest of the code.
However, there are also some potential problems associated with using mocks and interfaces:
- One common issue is overuse, where developers create too many interfaces and mocks, which can lead to increased complexity and reduced maintainability.
- Another problem is underuse, where developers do not use mocks and interfaces enough, which can make it difficult to test the code and lead to bugs.
- As always, this kind of choice brings a trade-off.
Tips for Overcoming the Pitfalls of Using Mocks and Interfaces
To overcome the pitfalls associated with using mocks and interfaces, it is important to strike a balance.
Developers should use mocks and interfaces when they are needed, but not overuse them. They should also make sure that their interfaces are well-defined and easy to understand. Additionally, developers should use tools like code coverage analysis to ensure that their tests are testing all the relevant parts of their code.
The use of mocks and interfaces is essential in TDD as they allow developers to test their code in isolation, making it easier to identify and fix bugs. While there are some pitfalls associated with using mocks and interfaces, these can be overcome by striking a balance and using the right tools. By using mocks and interfaces effectively, developers can create code that is flexible, easy to maintain, and bug-free.
Why mocking make sense to me Finally, I want to share with you the main reason why using mocks is a great technique and, in my experience, a fundamental one that can help us achieve good design.
Remember what Object Oriented Programming means?
A system of objects that communicates through messages.
Suppose we have a controller, a service that do something and a repository that writes a table, used from the service.
The controller only speaks to the services via messages (public methods exposing behaviour), doesn’t care and shouldn’t know that the service uses a repository or anything else.
When I test the controller, mocking the service method I’m using is a good way, IMHO, to ensure that the two objects are communicating well, and respecting the interface. I don’t need to test service behaviour, so having a mock or stub that ensures we communicated well is great, IMHO.
Go Deeper
Here are some resources you can check if you want to go deeper and learn more about Test Doubles.
Books
- Agile Technical Practices Distilled - has a full chapter on Test Doubles
Online
- Test Doubles - from Martin Fowler's blog
- Testing without mocks - from James Shore’s blog