REST API adapter (BuildIt side)
From this week and onwards, you will be implementing BuildIt’s information
system. This new application relies on RentIt’s information system, such that
the lack of some features in RentIt’s side can block the progress in the
implementation of BuildIt’s project. To break with this dependency, we will use
test mocks. A test mock is a fake implementation for a system component that
is used in a situation like ours. In our context, we will use a well known
library called Mockito
as described in the following subsection.
A RentIT mock service
As way of example, let us consider the implementation of the service that connects BuildIt application with RentIt’s as shown in the following snippet.
The connection to RentIt’s REST endpoint is made by means of spring’s
RestTemplate
class. This class provides methods for starting RESTful
interactions in a convenient way. In the example above, we are executing an HTTP
GET interaction, as hinted by the method’s name getForObject()
. The latter
method is called with the corresponding URI, and will return an array with
PlantInventoryEntryDTO
(it seems that RestTemplate
cannot return lists).
Note that we are using a URI template, and that we can just pass the values to
be replaced in the URI template at the end of the call.
The method above should already work with our prototype RentIt implementation. However, we would need to have an instance of RentIt running all the time, if we want to test something in BuildIt. This approach has several drawbacks (e.g. high memory/cpu requirements) and can block the progress in the development of the BuildIt implementation (e.g. if we needed to test a feature that is not yet implemented in RentIt). The alternative is to use a test mock. To that end, we will use Mockito, a popular test mock framework for java. We will provide the basic setup of Mockito for our Spring-based application, and will refer you to Mockito’s documentation to get further information.
Let us now have a look at the test code.
Note that the configuration of this test class is slightly different w.r.t. to
the previous ones. In this case, as specified in the line with bullet 1,
the class requires to load the configuration
specified by our project’s entry class (i.e. in this case ProcurementApplication
),
in addition to class ProcurementApplication.RentalServiceMock
which is defined
as an inner class, in the line marked with bullet 2. Note that the latter inner
class serves only to replace the instance of class RentalService
with a
mock created by Mockito in the line with bullet 3. Recall that a mock is a
Java object that implements the same interface as the original Java object, which
we will use to spy on the calls made towards the original Java object. The mock
object can also be use to setup fake responses to simulate the behavior that
is expected from the original Java object.
The line marked with bullet 5 shows how the mock object is configured with a
fake response. In that line, we are specifying that the mock object would return
a list of plant inventory entries when the application "interacts" with the
rental service, calling the method findAvailablePlants
. Instead of hardwiring
the list of plant inventory entries to be returned, we are storing them in a
separate json file called trucks.json
(as usual, the file should be located
in the source folder src/test/resources
, within a relative path that mirrors
the package of the test class). The line marked with bullet 4 and the subsequent
line show how to load the content of trucks.json
and parse its content to get
the corresponding list of plant inventory entries.