With this functionality you can have one centralized repository containing all contracts. This repo will have to produce a JAR containing all contracts. The layout of the repository can be arbitrary but some sensible defaults are assumed. The producer will be able to then download that JAR and produce tests and stubs from it. fixes #38
67 lines
2.4 KiB
Groovy
67 lines
2.4 KiB
Groovy
package contracts
|
|
|
|
org.springframework.cloud.contract.spec.Contract.make {
|
|
request { // (1)
|
|
method 'PUT' // (2)
|
|
url '/fraudcheck2' // (3)
|
|
body([ // (4)
|
|
clientId: value(consumer(regex('[0-9]{10}'))),
|
|
loanAmount: 99999
|
|
])
|
|
headers { // (5)
|
|
header('Content-Type', 'application/vnd.fraud.v1+json')
|
|
}
|
|
}
|
|
response { // (6)
|
|
status 200 // (7)
|
|
body([ // (8)
|
|
fraudCheckStatus: "FRAUD",
|
|
rejectionReason: "Amount too high"
|
|
])
|
|
headers { // (9)
|
|
header('Content-Type': value(
|
|
producer(regex('application/vnd.fraud.v1.json.*')),
|
|
consumer('application/vnd.fraud.v1+json'))
|
|
)
|
|
}
|
|
}
|
|
}
|
|
|
|
/*
|
|
Since we don't want to force on the user to hardcode values of fields that are dynamic
|
|
(timestamps, database ids etc.), one can provide parametrize those entries by using the
|
|
`value(consumer(...), producer(...))` method. That way what's present in the `consumer`
|
|
section will end up in the produced stub. What's there in the `producer` will end up in the
|
|
autogenerated test. If you provide only the regular expression side without the concrete
|
|
value then Spring Cloud Contract will generate one for you.
|
|
|
|
From the Consumer perspective, when shooting a request in the integration test:
|
|
|
|
(1) - If the consumer sends a request
|
|
(2) - With the "PUT" method
|
|
(3) - to the URL "/fraudcheck"
|
|
(4) - with the JSON body that
|
|
* has a field `clientId` that matches a regular expression `[0-9]{10}`
|
|
* has a field `loanAmount` that is equal to `99999`
|
|
(5) - with header `Content-Type` equal to `application/vnd.fraud.v1+json`
|
|
(6) - then the response will be sent with
|
|
(7) - status equal `200`
|
|
(8) - and JSON body equal to
|
|
{ "fraudCheckStatus": "FRAUD", "rejectionReason": "Amount too high" }
|
|
(9) - with header `Content-Type` equal to `application/vnd.fraud.v1+json`
|
|
|
|
From the Producer perspective, in the autogenerated producer-side test:
|
|
|
|
(1) - A request will be sent to the producer
|
|
(2) - With the "PUT" method
|
|
(3) - to the URL "/fraudcheck"
|
|
(4) - with the JSON body that
|
|
* has a field `clientId` that will have a generated value that matches a regular expression `[0-9]{10}`
|
|
* has a field `loanAmount` that is equal to `99999`
|
|
(5) - with header `Content-Type` equal to `application/vnd.fraud.v1+json`
|
|
(6) - then the test will assert if the response has been sent with
|
|
(7) - status equal `200`
|
|
(8) - and JSON body equal to
|
|
{ "fraudCheckStatus": "FRAUD", "rejectionReason": "Amount too high" }
|
|
(9) - with header `Content-Type` matching `application/vnd.fraud.v1+json.*`
|
|
*/ |