mockito

The danger of @InjectMocks

Last week, I wrote about the ways to initialize your Mockito’s mocks and my personal preferences. I’m still working on my legacy project, and I wanted to go deeper into some Mockito’s feature that are used. For example, Mockito’s developers took a real strong opinionated stance on the design: Mockito can only mock public non-final instance methods. That’s something I completely endorse.

Java

Initializing your Mockito mocks

Maintenance projects are not fun compared to greenfield projects, but they sure provide most of the meat for this blog. This week saw me not checking the production code but the tests. What you see in tests reveals much of how the production code itself is written. And it’s a way to change things for the better, with less risks. At first, I only wanted to remove as much PowerMock uses as possible. Then I found out most Mockito spies were not necessary.

Java

Mockito' spy() method and Spring

Mockito is a mocking framework (see Two different mocking approaches) that is an offshoot of EasyMock. Whatever the mocking framework one uses, a common feature is the ability to mock interfaces, through the JDK Proxy class. This is well and nice, but one has to explicitly mock every method that one wants to use in the course of the test. What if I want to mock an already existing implementation, with some methods providing behaviours that suit me ?

Java

Two different mocking approaches

Whether you choose to choose to adopt TDD or a more traditional approach, you will test your classes in isolation. This usually mean you code with interfaces and inject your dependencies in your classes. Last year, I had to test a servlet. Servlets are the showcase to demonstrate out-of-container testing because of their dependencies to said container in their doXxx() method. Every one of these methods has a dependency on HttpServletRequest and HttpServletResponse.