Thanks for submitting the form.
Introduction to Consumer-Driven Contract TestingIf you are working in the testing domain, you probably have heard about microservices. Many organizations who have moved into modern DevOps practices are also investing in converting or building new projects into Microservice-based architecture. Contract Testing in the Microservice architecture is about splitting the application into small standalone services, each of which plays a separate role in the overall system. Being a new technology, it comes with certain challenges, especially in the testing domain. Testers, especially web testers, are now figuring out new ways of automation testing approach in the world of microservices. Before digging deeper, let’s understand what is microservices.
Benefits of Monolithic architectureA Monolithic approach gives a boost a the beginning of the project. There is no need to define complex integration testing and deployment processes. Everything is trivialized to a single service.
- Single codebase — simple to develop (at least in the beginning).
- No need to verify integration with other services since they don’t exist.
- Relatively easy deployment process — only one service needs to be deployed.
- Single point of failure — if one app is down, the whole service is down.
- Maintenance complexity grows with time.
- Hard to adopt new technologies and techniques. Usually, it requires rewriting the application from scratch.
A/B testing is not only a one-off question or settling a disagreement; A/B testing is more than that. Source- A/B Testing Tools and Practices
Benefits of MicroservicesMicroservices have many advantages over monolithic architecture (where a single application takes responsibility for the whole system). The most important ones are listed below:
- No single point of failure. When one service is down users can still use the application. Other services are still working.
- Individual Microservices can be scaled up to increase their capacity and availability.
- Security — most of the services aren’t exposed to the Internet.
- Every service can be deployed independently of other services. Providing they don’t break the API contracts.
- Lots of work need to be invested to set up the foundation.
- Deployment processes are more complex. Some deployments may require deploying more than one service.
- Tons of work on DevOps. Especially with deployments.
- Dealing with integration testing.
- Ensure the code branch is correct.
- Pull the latest code from the repository.
- Ensure dependencies are all updated.
- Rerun if there is any database migration.
- Start the service.
Designing Microservices For Some ApplicationLet’s consider we have different services in an application like Website, Android App, iPhone App, API Gateway, User Service, Job Service, Payment Service, Email Service. The website and mobile apps communicate with services through the API Gateway. The API Gateway is the only way to access the services from the Internet. The services communicate with each other inside the internal network. Imagine a user creates a new account. They enter the website, fill in the form, and send the request to the API Gateway. The API Gateway delivers this request to the User Service that creates a new account. After creating an account, User Service sends a request to the E-Mail Service to send an activation e-mail. An e-mail is then sent with a link that the user needs to click to activate their account. As you noticed, the E-mail service isn’t available over the API Gateway. This is because only internal services can trigger e-mail notifications.
A process to check that the deployed build is stable or not, also helps a QA team to get confirmation so that team can proceed for further testing or not. Source- Smoke Testing
Consumer-Driven Contract TestingConsumer-driven contract tests are actually integration tests that are targetting your API, whether it’s REST-based or messaging-based. Imagine you’re working on an application that exposes its data using a REST API. Another team is using your exposed data for some functionality that they are providing. In order to guarantee that the functionality of the other team their application doesn’t break if we make changes to our API, we create a contract between the two teams. Key in this setup is that the contracts are defined by the consumer of your API instead of the developer that wrote the implementation of certain functionality. With this approach, we can generate tests by using those consumer-driven contracts and verify whether we’re going to break any of our consumers’ applications. Instead of running integration tests between all the services — get rid of them. All services communicate through RESTful APIs. That means that if we define a tight “contract” between APIs we don’t need to spin up the whole platform. It is enough to verify the fulfilment of the requirements of other services.
What is the Consumer?
- A consumer is a client that wants to receive some data from other services (for example, a web front end, or a message receiving endpoint).
- They define requirements towards the endpoint such as HTTP headers, status code, payload, and response.
- The contracts are generated during the unit test runtime.
- After all, tests succeed pact creates json files containing information on HTTP requests.
What is a Provider?
- A provider is a service or server that provides the data (for example, an API on a server that provides the data with the client needs, or the service that sends messages).
- A tool for verifying contracts towards provider is called Pact Provider Verifier. The verifier runs HTTP requests base on the contracts created by the consumer.
- If the server response is in the form expecteContact tracing may sound like taking your contacts out of your eyes and then drawing circles around them. d by the consumer, the tests pass.
How to Deliver Contracts to all Peers?After all tests on the consumer side succeed, the json files containing contracts are created. Our job is to deliver them to the providers to verify the contract. There are several ways of doing this listed below:
- Git repository for storing pacts, and including them into each project with a git submodule. In my opinion the best way of doing it,
- A file system.
- The Pact Broker.