Monolithic Architecture is a delicate balancing act, one that rests on understanding how any one change will affect the entire system.
This new trend is called Microservices Architecture. Instead of creating a single large application, the idea is to subdivide the single application into a set of different interconnected applications which will make it into a distributed one.
A Monitoring Tool developed by us which can primarily track Business Transactions that revolve around IBM Middlewares as well as system-metrics of respective Middlewares.
MonitorPro has a strict adherence to Microservices Architecture containing twelve Microservices.
Testing MonitorPro was quite tough because it’s written in different languages. The major issue comes to test these Distributed and Loosely-Coupled Microservices.
Let’s suppose three (03) classes each having four (04) code paths so, how many test cases
Ans. 4*4*4= 64 Test Cases.
With the concept of Consumer-Driven Contract Testing, a contract is an accumulation of agreements between an API Provider and a client contracts that describes the interactions that can take place between them.
Pact: is a testing Framework that helps you write contracts and guarantees those contracts are satisfied.
For our use case we wrote test cases on the following versions of Pact written in these languages:- (no language examples)
The expectations are set up on a mock service provider the tests for the provider facing code in the consumer project.
When the tests are executed, the mock service returns the anticipated responses. The requests, and their expected responses, are then written to a “pact” file.
The calls/requests in the (pact file) are thereafter rerun against the provider, and the real responses are examined to confirm they match the expected responses.
The above image shows the complete working of Pact.
Step1:- Setting expectations on Mock Server Provider
We have to do an API call with any HTTP Client Library and we are all set.
We get the following JSON File generated:-
Step 2:- Pact Files Generated and Publishing to Pact Broker
Once we have got the Pact Files which is in JSON format, it needs to be published to Pact Broker or any code repository or may be in your local system from where it can be fetched and replayed against Providers.
So there are various ways you can choose what best fits for your Project and follow accordingly.
For MonitorPro we had a dedicated Pact Broker which can be installed using docker-compose file.
Now, we have to publish the pact files to this Pact Broker which was done using Pact-Maven Plugin. Add this in pom.xml on Consumer side.
Step 3:- Verifying Pacts on Provider Side
That’s it if you are still following means you are good learner. In this last step our verification will happen which will convey that we are all good for production.