Adjustments to the Original Source Code
We created new entities and added them to the database if additional data for integration tests were required. Within each InitData class that required additional data, we created a utility method and named it after the service that requires this data for integration testing. For instance, the ts-travel-service needed to have additional data on service startup to allow for a successfully running test in the ts-preserve-service, we added a utility method called insertForPreserve() in the InitData class of the ts-travel-service:
Besides the ts-travel-service, we also added startup data initialization methods to the following services:
ts-travel2-servicets-order-servicets-order-other-servicets-train-servicets-contacts-servicets-user-service
Each of these services received similar utility methods for data initialization following the same pattern demonstrated in the ts-travel-service. These changes were implemented as part of a single commit and can be viewed here.
Four faults (F5, F9, F11, and F16) blocked the proper execution of integration tests involving these services and required resolution.
F5 involves an incorrect null-check with an Optional return type in the ts-train-service and ts-station-service. This incorrect check causes the create method of both services to consistently fail. Since the InitData classes of both services use this create method to initialize its database on startup, their databases are consistently empty, which hinders proper testing of services for integration tests that utilize this service.
We were able to resolve this blocker without directly addressing F5 by altering the InitData classes in question to directly save their entities to the database instead of invoking the faulty create service method:
This way, the ts-train-service and ts-station-service contain elements in their database, which will be used as testing data from other services, without actually altering the implementation of these services.
The entire commit containing these adjustments to the ts-train-service and ts-station-service to circumvent F5 can be viewed here.
Without appropriate annotations or implementation for manual date transformation, both ts-order-service and ts-order-other-service fail to convert Date objects to a string in paths, making their URLs containing dates dysfunctional.
As these endpoints containing dates are invoked regularly by other services, this fault would lead to failing integration tests for a majority of services. We resolved this fault by changing the Date object as path variable to a string, and then manually convert that string to a date object before invoking the service implementation:
Resolving F9 was part of a single commit that can be viewed here.
The fallback method in the controller class of the ts-user-service returns HttpEntity, while other methods in the same context returns ResponseEntity<Response>. This mismatch causes a compile time error when the service is executed, which leads to failing integration test cases for all services which involve this service.
Therefore, this mismatch had to be resolved by changing the return value fo the fallback response from HttpEntity to ResponseEntity<Response> in the UserController class:
The timeout values in the controller classes of the ts-preserve-service and the ts-preserve-other-service are set to 5000 milliseconds, which is insufficient for a successful execution of their endpoints.
Therefore, in order to be able to test both services fully, the timeout value within both controller classes has been increased from 5000 milliseconds to 20000 milliseconds:
