Example of role tests in Java with Junit
Published by Manuel Rivero on 02/08/2022
I’d like to continue with the topic of role tests that we wrote about in a previous post, by showing an example of how it can be applied in Java to reduce duplication in your tests.
This example comes from a deliberate practice session I did recently with some people from Women Tech Makers Barcelona with whom I’m doing Codesai’s Practice Program in Java twice a month.
Making additional changes to the code that resulted from solving the Bank Kata we wrote the following tests to develop two different implementations of the
TransactionsRepository port: the
InMemoryTransactionsRepository and the
These are their tests, respectively:
As you can see both tests contain the same test cases:
transactions_can_be_retrieved but their implementations are different for each class. This makes sense because both implementations implement the same role, (see our previous post to learn how this relates to Liskov Substitution Principle).
We can make this fact more explicit by using role tests. In this case, Junit does not have something equivalent or similar to the RSpec’s shared examples functionality we used in our previous example in Ruby. Nonetheless, we can apply the Template Method pattern to write the role test, so that we remove the duplication, and more importantly make the contract we are implementing more explicit.
To do that we created an abstract class,
TransactionsRepositoryRoleTest. This class contains the tests cases that document the role and protect its contract (
transactions_can_be_retrieved) and defines hooks for the operations that will vary in the different implementations of this integration test
Then we made the previous tests extend
TransactionsRepositoryRoleTest and implemented the hooks.
This is the new code of
And this is the new code of
FileTransactionsRepositoryTest after the refactoring:
This new version of the tests not only reduces duplication, but also makes explicit and protects the behaviour of the
TransactionsRepository role. It also makes less error prone the process of adding a new implementation of
TransactionsRepository because just by extending the
TransactionsRepositoryRoleTest, you’d get a checklist of the behaviour you need to implement to ensure substitutability, i.e., to ensure the Liskov Substitution Principle is not violated.
Have a look at this Jason Gorman’s repository to see another example that applies the same technique.
I’d like to thank the WTM study group, and especially Inma Navas and Laura del Toro for practising with this kata together.
Thanks to my Codesai colleagues, Inma Navas and Laura del Toro for reading the initial drafts and giving me feedback, and to Esranur Kalay for the picture.
- Role tests for implementation of interfaces discovered through TDD , Manuel Rivero
- Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Ralph Johnson, John Vlissides, Richard Helm
- Liskov Substitution Principle
- 101 Uses For Polymorphic Testing (Okay… Three), Jason Gorman
- Contract Testing example repository, Jason Gorman
Photo from Esranur Kalay in Pexels
Originally published in Manuel Rivero's blog.