Skip to content

Latest commit

 

History

History
121 lines (86 loc) · 4.86 KB

README.adoc

File metadata and controls

121 lines (86 loc) · 4.86 KB
Raw

Arquillian Algeron

Table of Contents

Build Status

Important
 Using Arquillian Algeron Pact Provider requires at least Arquillian Core 1.1.12.Final or above.
Important
 Arquillian Algeron Pact 1.X works with versions of Pact previous to 3.5.0. Arquillian Algeron Pact 2.X works with Pact 3.5.0.

To read complete documentation visit http://arquillian.org/arquillian-algeron/

1. Migration from Arquillan Algeron Pact 1.X to 2.X

With the release of Pact 3.5.0, toFragment method has been deprecated in favor of toPact(). Also this method instead of returning PactFragment now returns RequestResponsePact.

Because of this change your contract definition should be adapted accordingly:

Algeron Pact 1.X
@Pact(provider = "test_provider", consumer = "test_consumer")
public PactFragment createFragment(PactDslWithProvider builder) {

    Map<String, String> header = new HashMap<>();
    header.put("Content-Type", "application/json");

    return builder
        .given("test state")
        .uponReceiving("ConsumerTest test interaction")
        .path("/")
        .method("GET")
        .willRespondWith()
        .status(200)
        .headers(header)
        .bodyWithSingleQuotes(("{'responsetest': true, 'name': 'harry'}"))
        .toFragment();
}

to:

Algeron Pact 2.X
@Pact(provider = "test_provider", consumer = "test_consumer")
public RequestResponsePact createFragment(PactDslWithProvider builder) {

    Map<String, String> header = new HashMap<>();
    header.put("Content-Type", "application/json");

    return builder
        .given("test state")
        .uponReceiving("ConsumerTest test interaction")
        .path("/")
        .method("GET")
        .willRespondWith()
        .status(200)
        .headers(header)
        .bodyWithSingleQuotes(("{'responsetest': true, 'name': 'harry'}"))
        .toPact();
}

2. What is Arquillian Algeron?

In microservices architecture you typically have one or more services that make remote calls to one or more services to get information from them.

For example you might have one service called BeerService that returns information of a beer. But this service needs to call another service CommentsService which returns the comments that users has done for given beer. After BeerService receives all the comments for that beer, everything is packed and sent to the client.

So as you can see there is a communication between both services where one needs to know what and how to send data such as name of fields, type of data or status code (CommentsService) and another one that needs to know how to interpret what is received (BeerService).

It seems obvious that it must exist some kind of agreement between them so they can understand each other correctly in all of their communications.

3. Consumer Driven Contracts

A Contract is a collection of agreements between a client ( or Consumer which in previous example is BeerService) and an API (or Provider which in previous example is CommentsService) that describes the interactions that can take place between them.

In summary Consumer Driven Contracts is a pattern that drives the development of the Provider from its Consumers point of view. This means that consumer describes what and how he wants to receive the information, describing in form of contract and then provider implements its service following that contract. When the client validates that can consume what it is been defined in the contract and provider validates that what he produces meets the contract, then you can be sure that contract expectations are met and they will be able to communicate each other.

Also notice that thanks of these tests, if anyone changes the client or the server side to not meet the contract, you’ll detect before it is deployed to production.

You can read more about Consumer-Driven contracts here or at book Testing Java Microservices chapter 6.