'PACT vs spring cloud contract tests [closed]

I am trying to understand the better tool between PACT and Spring Cloud Contract to implement Consumer Driver Contract Tests. I dont find any clear examples to find the pros and cons.

I want to implement CDCT, and I dont use Spring in my project. From what i understood I am assuming PACT is good to go with.

Any information or suggestions are welcomed. Thank you.

pactspring-cloud-contract


Solution 1:[1]

Spring Cloud Contract allows you to define and test contracts for both REST APIs and messaging. It provides a clear and easy to use statically typed Groovy DSL and also allows for defining contracts via yaml. Both with the DSL and with yaml, defining contracts is very intuitive to anyone familiar with the standard HTTP/messaging terms, for example:

request {
    method PUT()
    url '/fraudcheck'
    body([
           "client.id": $(regex('[0-9]{10}')),
           loanAmount: 99999
    ])
    headers {
        contentType('application/json')
    }
}
response {
    status OK()
    body([
           fraudCheckStatus: "FRAUD",
           "rejection.reason": "Amount too high"
    ])
    headers {
        contentType applicationJson()
    }
}

The producer-side tests are automatically generated by SCC and added to the project during build. If a correct implementation fulfilling the contracts is not in place, the project will not be built and deployed. If they pass, the stubs for consumer will be generated and published along with the corresponding artifact version.

On the consumer side, for HTTP, SCC provides the Stubrunner, that launches a Wiremock (in-memory http server) instance, that provides stubbed responses to matching requests. Stubrunner works with external artifact repositories such as Nexus and Artifactory and also with local m2 repositories.

SCC integrates with SpringBoot seamlessly and also integrates with Spring Cloud out of the box and can be used in place of service discovery during integration tests.

It also integrates out of the box with Pact and allows to leverage additional Pact features via hooks while using only the SCC contracts definitions.

SCC also provides a Docker-based option for implementing and testing contracts in technologies other than JVM.

DISCLAIMER: I’m a Spring Cloud Contract committer.

Solution 2:[2]

In contract testing, we want to make sure that the provider and consumer of an API are compatible with each other. Therefore we define our expectations as a contract using a DSL and test it against the consumer or provider of the API and if it is successful then publish it (via manually copying it or publishing to a shared repository) to the other side of the contract (Provider or consumer).

Two main providers of such functionality are: Pact and SCC (Spring Cloud Contract)

PACT: Pact is a consumer-driven contract meaning that we define and validate the contract on the consumer side and then push it to the provider side for validation. Additionally, Pact is not limited to a specific framework or even language (pact-JVM is there for a Java application). Also, it integrates well with Spring (Boot) and you can define pact test while starting the whole application (@SpringBootTest) or during Slice testing (@WebMvcTest).

SCC: Generally it encourages provider-driven contracts, meaning that you define the contract on the provider side and if it validates then publish it to the consumer side. However, we can do it the other way around or even we can define the contract separately and test it manually against the producer and consumer.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1
Solution 2 Community

Related Questions