Advanced testing with Mockito

1.1 Mockito library

Today we will get acquainted with advanced testing. More specifically, with the Mockito library . Don't even think about getting out of this business.

First, this library is a standard in Spring testing . Which is actually the standard in the Java backend development industry.

Secondly, you will have to write tests for your Spring code . The only way to understand that the backend you wrote works as it should is to call methods of its API . And doing it with tests is 10 times easier than without them. You will see for yourself.

You can add the Mockito library to yours pom.xmlusing the code:

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-junit-jupiter</artifactId>
    <version>4.2.0</version>
    <scope>test</scope>
</dependency>

The entire source code for the Mockito project can be found on GitHub .

1.2 Mock objects

So what is this Mockito and why is it so good?

In the process of development and development of testing, very often there was a need to slip some kind of “stub” into the code instead of a real object.

For example, the code that works with the database is tested and changes something there. It is good that before each test the state of this database is the same (otherwise the tests will be different). And I would like the base to be simpler in order to quickly roll back these states.

Or, for example, you are testing a code that sends useful SMS. And for direct mailings, he uses some kind of paid SMS Gateway. It would be nice to slip some virtual Gateway into it to test the code, so as not to send hundreds of SMS to incomprehensible people.

Or your code is requesting data from other web servers that are simply not available on the test server. Or you write a code for online payments that needs to be tested 50 times, and only then allowed to be used in real financial channels.

I think you understand ... Virtual objects, or as they are also called stub objects, are a very useful thing.

And here comes the difficulty - Java has static typing. This means that in order to ReadDatabaseassign a reference to an object to a variable instead of an object of type VirtualDatabase, you need to inherit the class VirtualDatabasefrom RealDatabase.

Then it turns out that the class has RealDatabasea bunch of private methods and variables that store references to other real objects, and you can’t write a normal stub in this way. In theory it's good, but in practice it's a dead end.

And here comes to the rescue ( you can readDynamicProxy in more detail ), which appeared back in Java 5. It allows you to create virtual objects that the compiler has no complaints about.

Such virtual objects are called mocks (from the word mock - layout). The Mockito library was able to take the work with these mocks to an unprecedented height. Hence, by the way, the name of the library.

1.3 @ExtendWith annotation

The Mockito library works great with JUnit, it can even be considered an extension of it.

There are two ways to enable the Mockito library in your unit tests. The first way is to add a special annotation:

@ExtendWith(MockitoExtension.class)
public class MockitoAnnotationTest {
    ...
}

The second way is to enable its work by calling the method openMocks():

public class MockitoAnnotationTest {
    @BeforeEach
    public void init() {
        MockitoAnnotations.openMocks(this);
   }
}

Most often, you will see the first option, but sometimes it is useful to know that there is a second one.