I – and probably many others too – have already stumbled upon this idea. At first glance, mocks offer a simple solution: you just have to simulate the relevant method calls, you can write a test relatively quickly and achieve high test coverage. However, this is where the problem lies.
A use case in a business application rarely consists of an atomically programmed piece, such as a sorting algorithm, but rather of a sequence of several steps that take place in different components.
A bug is reported from production but all tests are green? Or refactorings are carried out and force the tests to be rebuilt on a large scale at the same time – so that in the end it remains unclear whether the refactoring was even error-free? Such situations often indicate tests with heavy use of mocks. This article uses a concrete project example to show whether and how you can do without mocks in backend tests of business applications, what advantages this brings and how well-structured tests can still be implemented.
The use of Mockito then ensures that the tests are decoupled from reality. There is a discrepancy between what the tests show and the actual behavior of the application.
That was the excerpt from our heise-Plus article “Why mocks in business applications often do more harm than good”. With a heise Plus subscription you can read the entire article.
