Menu
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.
454
Spring Cloud Contract Verifier is a tool that enables Consumer Driven Contract (CDC) development of JVM-based applications. It is shipped with Contract Definition Language (DSL) written in Groovy or YAML.
Pact is a code-first contract testing tool, that requires access to the code on both sides of an integration point. To be able to write Pact tests, you need to be able to write a unit test of the consumer, and to be able to manipulate state (usually within the context of a unit test) on the provider side.
Contract testing is a lightweight form of API testing that strictly checks the content and format of requests and responses. Unlike functional tests, contract tests do not validate the logic or consumer flows of APIs.
Contract tests assert that inter-application messages conform to a shared understanding that is documented in a contract. Without contract testing, the only way to ensure that applications will work correctly together is by using expensive and brittle integration tests.
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.
154
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
