Nowadays, enterprise applications are enormous. This is why the verification of such systems is a very important stage in any modern development life cycle. However, we should remember that in large systems there are a vast number of components and services, which in turn may include a large number of classes. For this reason, we should follow the Test Pyramid suggestions in order to cover everything. Here, the basic part of system testing is unit testing.

In our case, the subject of the testing is code written using the reactive programming technique. As we discovered in Chapter 3, Reactive Streams - the New Streams' Standard and Chapter 4, Project Reactor - the Foundation for Reactive Apps, reactive programming gives us a bunch of benefits. The first of these is the ability to optimize resource usage by enabling asynchronous communication. In turn, such a model fits well for building non-blocking I/O communication. Moreover, the ugly asynchronous code may be transformed into clean code using a reactive library such as Reactor. Reactor brings substantial functionality that simplifies the application's development.

However, along with the benefits, there is also a considerable drawback to testing such code. First of all, since that code is asynchronous, there is no easy way to pick the returned element and check whether it is correct. As we might remember from Chapter 3, Reactive Streams - the New Streams' Standard, we may collect elements from any Publisher by implementing the Subscriber interface and using it to check the accuracy of the emitted results. We may potentially end up with a complex solution from this, which is not an ideal situation for a developer when testing code.

Fortunately, Reactor's team did their best to simplify the verification of the code written using Reactive Streams.