![[Important]](images/important.png) | Important | |||||
|---|---|---|---|---|---|---|
Remember that, inside the contract file, you have to provide the fully + Spring Cloud Contract supports out of the box 2 types of DSL. One written in
+ If you decide to write the contract in Groovy, do not be alarmed if you have not used Groovy +before. Knowledge of the language is not really needed, as the Contract DSL uses only a +tiny subset of it (only literals, method calls and closures). Also, the DSL is statically +typed, to make it programmer-readable without any knowledge of the DSL itself.
Contract DSL is written in Groovy, but do not be alarmed if you have not used Groovy -before. Knowledge of the language is not really needed, as the Contract DSL uses only a -tiny subset of it (only literals, method calls and closures). Also, the DSL is statically -typed, to make it programmer-readable without any knowledge of the DSL itself.
The Contract is present in the The following is a complete example of a contract definition: org.springframework.cloud.contract.spec.Contract.make {
+ |
![[Tip]](images/tip.png) | Tip |
|---|---|
Spring Cloud Contract supports defining multiple contracts in a single file. |
The following is a complete example of a Groovy contract definition:
org.springframework.cloud.contract.spec.Contract.make {
request {
method 'PUT'
url '/api/12'
@@ -48,18 +47,66 @@ Cloud Contract Verifier repository.The following is a complete exampl
'''
}
response {
- status 200
+ status OK()
}
-}
![[Note]](images/note.png) | Note |
|---|---|
The preceding example does not contain all the features of the DSL appear. The -remainder of this section describes the other features. |
You can compile Contracts to WireMock stubs mapping using standalone maven command:
-mvn org.springframework.cloud:spring-cloud-contract-maven-plugin:convert
![[Warning]](images/warning.png) | Warning | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Spring Cloud Contract Verifier does not properly support XML. Please use JSON or +} The following is a complete example of a YAML contract definition: description: Some description +name: some name +priority: 8 +ignored: true +request: + url: /foo + queryParameters: + a: b + b: c + method: PUT + headers: + foo: bar + fooReq: baz + body: + foo: bar + matchers: + body: + - path: $.foo + type: by_regex + value: bar + headers: + - key: foo + regex: bar +response: + status: 200 + headers: + foo2: bar + foo3: foo33 + fooRes: baz + body: + foo2: bar + foo3: baz + nullValue: null + matchers: + body: + - path: $.foo2 + type: by_regex + value: bar + - path: $.foo3 + type: by_command + value: executeMe($it) + - path: $.nullValue + type: by_null + value: null + headers: + - key: foo2 + regex: bar + - key: foo3 + command: andMeToo($it)
The following sections describe the most common top-level elements: You can add a org.springframework.cloud.contract.spec.Contract.make {
+following code shows an example:You can provide a name for your contract. Assume that you provided the following name: + } + YAML. + description: Some description +name: some name +priority: 8 +ignored: true +request: + url: /foo + queryParameters: + a: b + b: c + method: PUT + headers: + foo: bar + fooReq: baz + body: + foo: bar + matchers: + body: + - path: $.foo + type: by_regex + value: bar + headers: + - key: foo + regex: bar +response: + status: 200 + headers: + foo2: bar + foo3: foo33 + fooRes: baz + body: + foo2: bar + foo3: baz + nullValue: null + matchers: + body: + - path: $.foo2 + type: by_regex + value: bar + - path: $.foo3 + type: by_command + value: executeMe($it) + - path: $.nullValue + type: by_null + value: null + headers: + - key: foo2 + regex: bar + - key: foo3 + command: andMeToo($it) + You can provide a name for your contract. Assume that you provided the following name:
|
Groovy DSL. +
org.springframework.cloud.contract.spec.Contract.make {
+ name("some_special_name")
+}+
YAML. +
name: some name
+
If you want to ignore a contract, you can either set a value of ignored contracts in the
+plugin configuration or set the ignored property on the contract itself:
Groovy DSL. +
org.springframework.cloud.contract.spec.Contract.make {
ignored()
-}Starting with version 1.2.0, you can pass values from files. Assume that you have the
+}
+
YAML. +
ignored: true
+
Starting with version 1.2.0, you can pass values from files. Assume that you have the
following resources in our project.
└── src
└── test
└── resources
└── contracts
├── readFromFile.groovy
├── request.json
- └── response.jsonFurther assume that your contract is as follows:
import org.springframework.cloud.contract.spec.Contract
+ └── response.jsonFurther assume that your contract is as follows:
Groovy DSL. +
import org.springframework.cloud.contract.spec.Contract Contract.make { request { @@ -96,17 +205,26 @@ Contract.make { url("/1") } response { - status 200 + status OK() body(file("response.json")) headers { contentType(textPlain()) } } -}
Further assume that the JSON files is as follows:
request.json
{ "status" : "REQUEST" }
response.json
{ "status" : "RESPONSE" }
When test or stub generation takes place, the contents of the file is passed to the body
-of a request or a response. That works because of the file(…) method. The argument of
-that method needs to be a file with location relative to the folder in which the contract
-lays.
The following methods can be called in the top-level closure of a contract definition.
-request and response are mandatory. priority is optional.
org.springframework.cloud.contract.spec.Contract.make {
+}+
YAML. +
request: + method: GET + url: /foo + bodyFromFile: request.json +response: + status: 200 + bodyFromFile: response.json
+
Further assume that the JSON files is as follows:
request.json
{ "status" : "REQUEST" }
response.json
{ "status" : "RESPONSE" }
When test or stub generation takes place, the contents of the file is passed to the body +of a request or a response. The name of the file needs to be a file with location +relative to the folder in which the contract lays.
The following methods can be called in the top-level closure of a contract definition.
+request and response are mandatory. priority is optional.
Groovy DSL. +
org.springframework.cloud.contract.spec.Contract.make {
// Definition of HTTP request part of the contract
// (this can be a valid request or invalid depending
// on type of contract being specified).
@@ -125,8 +243,18 @@ lays.// Contract priority, which can be used for overriding // contracts (1 is highest). Priority is optional. priority 1 -}
The HTTP protocol requires only method and address to be specified in a request. The -same information is mandatory in request definition of the Contract.
org.springframework.cloud.contract.spec.Contract.make {
+}+
YAML. +
priority: 8 +request: +... +response: +...
+
| Important |
|---|---|
If you want to make your contract have a higher value of priority
+you need to pass a lower number to the |
The HTTP protocol requires only method and url to be specified in a request. The +same information is mandatory in request definition of the Contract.
Groovy DSL. +
org.springframework.cloud.contract.spec.Contract.make {
request {
// HTTP request method (GET/POST/PUT/DELETE).
method 'GET'
@@ -138,8 +266,13 @@ same information is mandatory in request definition of the Contract.//...
}
-}
It is possible to specify an absolute rather than relative url, but using urlPath is
-the recommended way, as doing so makes the tests host-independent.
org.springframework.cloud.contract.spec.Contract.make {
+}
+
YAML.
+
method: PUT
+url: /foo
+
It is possible to specify an absolute rather than relative url, but using urlPath is
+the recommended way, as doing so makes the tests host-independent.
Groovy DSL.
+
org.springframework.cloud.contract.spec.Contract.make {
request {
method 'GET'
@@ -150,8 +283,13 @@ the recommended way, as doing so makes the tests ho
response {
//...
}
-}request may contain query parameters, which are specified in a closure nested in a
-call to urlPath or url.
org.springframework.cloud.contract.spec.Contract.make {
+}
+
YAML.
+
request:
+ method: PUT
+ urlPath: /foo
+
request may contain query parameters.
Groovy DSL.
+
org.springframework.cloud.contract.spec.Contract.make {
request {
//...
@@ -191,7 +329,62 @@ call to urlPath or url
response {
//...
}
-}request may contain additional request headers, as shown in the following example:
org.springframework.cloud.contract.spec.Contract.make {
+}
+
YAML.
+
request:
+...
+ queryParameters:
+ a: b
+ b: c
+ headers:
+ foo: bar
+ fooReq: baz
+ cookies:
+ foo: bar
+ fooReq: baz
+ body:
+ foo: bar
+ matchers:
+ body:
+ - path: $.foo
+ type: by_regex
+ value: bar
+ headers:
+ - key: foo
+ regex: bar
+response:
+ status: 200
+ headers:
+ foo2: bar
+ foo3: foo33
+ fooRes: baz
+ body:
+ foo2: bar
+ foo3: baz
+ nullValue: null
+ matchers:
+ body:
+ - path: $.foo2
+ type: by_regex
+ value: bar
+ - path: $.foo3
+ type: by_command
+ value: executeMe($it)
+ - path: $.nullValue
+ type: by_null
+ value: null
+ headers:
+ - key: foo2
+ regex: bar
+ - key: foo3
+ command: andMeToo($it)
+ cookies:
+ - key: foo2
+ regex: bar
+ - key: foo3
+ predefined:
+
request may contain additional request headers, as shown in the following example:
Groovy DSL.
+
org.springframework.cloud.contract.spec.Contract.make {
request {
//...
@@ -208,7 +401,40 @@ call to urlPath or url
response {
//...
}
-}request may contain a request body, as shown in the following example:
org.springframework.cloud.contract.spec.Contract.make {
+}
+
YAML.
+
request:
+...
+headers:
+ foo: bar
+ fooReq: baz
+
request may contain additional request cookies, as shown in the following example:
Groovy DSL.
+
org.springframework.cloud.contract.spec.Contract.make {
+ request {
+ //...
+
+ // Each Cookies is added in form `'Cookie-Key' : 'Cookie-Value'`.
+ // there are also some helper methods
+ cookies {
+ cookie 'key': 'value'
+ cookie('another_key', 'another_value')
+ }
+
+ //...
+ }
+
+ response {
+ //...
+ }
+}
+
YAML.
+
request:
+...
+cookies:
+ foo: bar
+ fooReq: baz
+
request may contain a request body:
Groovy DSL.
+
org.springframework.cloud.contract.spec.Contract.make {
request {
//...
@@ -220,8 +446,15 @@ call to urlPath or url
response {
//...
}
-}request may contain multipart elements. To include multipart elements, call the
-multipart() method, as shown in the following example
org.springframework.cloud.contract.spec.Contract contractDsl = org.springframework.cloud.contract.spec.Contract.make {
+}
+
YAML.
+
request:
+...
+body:
+ foo: bar
+
request may contain multipart elements. To include multipart elements, use the
+multipart method/section, as shown in the following examples
Groovy DSL.
+
org.springframework.cloud.contract.spec.Contract contractDsl = org.springframework.cloud.contract.spec.Contract.make {
request {
method "PUT"
url "/multipart"
@@ -238,17 +471,75 @@ call to urlPath or url
// name of the file
name: $(c(regex(nonEmpty())), p('filename.csv')),
// content of the file
- content: $(c(regex(nonEmpty())), p('file content')))
+ content: $(c(regex(nonEmpty())), p('file content')),
+ // content type for the part
+ contentType: $(c(regex(nonEmpty())), p('application/json')))
+ )
+ }
+ response {
+ status OK()
+ }
+}
+org.springframework.cloud.contract.spec.Contract contractDsl = org.springframework.cloud.contract.spec.Contract.make {
+ request {
+ method "PUT"
+ url "/multipart"
+ headers {
+ contentType('multipart/form-data;boundary=AaB03x')
+ }
+ multipart(
+ file: named(
+ name: value(stub(regex('.+')), test('file')),
+ content: value(stub(regex('.+')), test([100, 117, 100, 97] as byte[]))
+ )
)
}
response {
status 200
}
-}In the preceding example, we define parameters in either of two ways:
- Directly, by using the map notation, where the value can be a dynamic property (such as
+}
+
YAML.
+
request:
+ method: PUT
+ url: /multipart
+ headers:
+ Content-Type: multipart/form-data;boundary=AaB03x
+ multipart:
+ params:
+ # key (parameter name), value (parameter value) pair
+ formParameter: '"formParameterValue"'
+ someBooleanParameter: true
+ named:
+ - paramName: file
+ fileName: filename.csv
+ fileContent: file content
+ matchers:
+ multipart:
+ params:
+ - key: formParameter
+ regex: ".+"
+ - key: someBooleanParameter
+ predefined: any_boolean
+ named:
+ - paramName: file
+ fileName:
+ predefined: non_empty
+ fileContent:
+ predefined: non_empty
+response:
+ status: 200
+
In the preceding example, we define parameters in either of two ways:
Groovy DSL
- Directly, by using the map notation, where the value can be a dynamic property (such as
formParameter: $(consumer(…), producer(…))). - By using the
named(…) method that lets you set a named parameter. A named parameter
can set a name and content. You can call it either via a method with two arguments,
such as named("fileName", "fileContent"), or via a map notation, such as
-named(name: "fileName", content: "fileContent").
From this contract, the generated test is as follows:
// given:
+named(name: "fileName", content: "fileContent").
YAML
- The multipart parameters are set via
multipart.params section - The named parameters (the
fileName and fileContent for a given parameter name)
+can be set via the multipart.named section. That section contains
+the paramName (name of the parameter), fileName (name of the file),
+fileContent (content of the file) fields The dynamic bits can be set via the matchers.multipart section
- for parameters use the
params section that can accept
+regex or a predefined regular expression - for named params use the
named section where first you
+define the parameter name via paramName and then you can pass the
+parametrization of either fileName or fileContent via
+regex or a predefined regular expression
From this contract, the generated test is as follows:
// given:
MockMvcRequestSpecification request = given()
.header("Content-Type", "multipart/form-data;boundary=AaB03x")
.param("formParameter", "\"formParameterValue\"")
@@ -271,11 +562,11 @@ such as named("fileName", "fileContent"), or via a
}
},
"bodyPatterns" : [ {
- "matches" : ".*--(.*)\\r\\nContent-Disposition: form-data; name=\\"formParameter\\"\\r\\n(Content-Type: .*\\r\\n)?(Content-Length: \\\\d+\\r\\n)?\\r\\n\\".+\\"\\r\\n--\\\\1.*"
+ "matches" : ".*--(.*)\\r\\nContent-Disposition: form-data; name=\\"formParameter\\"\\r\\n(Content-Type: .*\\r\\n)?(Content-Transfer-Encoding: .*\\r\\n)?(Content-Length: \\\\d+\\r\\n)?\\r\\n\\".+\\"\\r\\n--\\\\1.*"
}, {
- "matches" : ".*--(.*)\\r\\nContent-Disposition: form-data; name=\\"someBooleanParameter\\"\\r\\n(Content-Type: .*\\r\\n)?(Content-Length: \\\\d+\\r\\n)?\\r\\n(true|false)\\r\\n--\\\\1.*"
+ "matches" : ".*--(.*)\\r\\nContent-Disposition: form-data; name=\\"someBooleanParameter\\"\\r\\n(Content-Type: .*\\r\\n)?(Content-Transfer-Encoding: .*\\r\\n)?(Content-Length: \\\\d+\\r\\n)?\\r\\n(true|false)\\r\\n--\\\\1.*"
}, {
- "matches" : ".*--(.*)\\r\\nContent-Disposition: form-data; name=\\"file\\"; filename=\\"[\\\\S\\\\s]+\\"\\r\\n(Content-Type: .*\\r\\n)?(Content-Length: \\\\d+\\r\\n)?\\r\\n[\\\\S\\\\s]+\\r\\n--\\\\1.*"
+ "matches" : ".*--(.*)\\r\\nContent-Disposition: form-data; name=\\"file\\"; filename=\\"[\\\\S\\\\s]+\\"\\r\\n(Content-Type: .*\\r\\n)?(Content-Transfer-Encoding: .*\\r\\n)?(Content-Length: \\\\d+\\r\\n)?\\r\\n[\\\\S\\\\s]+\\r\\n--\\\\1.*"
} ]
},
"response" : {
@@ -284,21 +575,31 @@ such as named("fileName", "fileContent"), or via a
}
}
'''
The response must contain an HTTP status code and may contain other information. The -following code shows an example:
org.springframework.cloud.contract.spec.Contract.make {
+following code shows an example:Groovy DSL.
+
org.springframework.cloud.contract.spec.Contract.make {
request {
//...
}
response {
// Status code sent by the server
// in response to request specified above.
- status 200
+ status OK()
}
-}Besides status, the response may contain headers and a body, both of which are
-specified the same way as in the request (see the previous paragraph).
The contract can contain some dynamic properties: timestamps, IDs, and so on. You do not +}
+
YAML. +
response: +... +status: 200
+
Besides status, the response may contain headers, cookies and a body, both of which are +specified the same way as in the request (see the previous paragraph).
| Tip |
|---|---|
Via the Groovy DSL you can reference the |
The contract can contain some dynamic properties: timestamps, IDs, and so on. You do not
want to force the consumers to stub their clocks to always return the same value of time
-so that it gets matched by the stub. You can provide the dynamic parts in your contracts
-in two ways: pass them directly in the body or set them in separate sections called
-testMatchers and stubMatchers.
You can set the properties inside the body either with the value method or, if you use
+so that it gets matched by the stub.
For Groovy DSL you can provide the dynamic parts in your contracts
+in two ways: pass them directly in the body or set them in a separate section called
+bodyMatchers.
| Note |
|---|---|
Before 2.0.0 these were set using |
For YAML you can only use the matchers section.
| Important |
|---|---|
This section is valid only for Groovy DSL. Check out the +Section 8.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature. |
You can set the properties inside the body either with the value method or, if you use
the Groovy map notation, with $(). The following example shows how to set dynamic
properties with the value method:
value(consumer(...), producer(...)) value(c(...), p(...)) @@ -307,7 +608,8 @@ value(client(...), server(...))
The following example shows how to set d $(c(...), p(...)) $(stub(...), test(...)) $(client(...), server(...))
Both approaches work equally well. stub and client methods are aliases over the consumer
-method. Subsequent sections take a closer look at what you can do with those values.
You can use regular expressions to write your requests in Contract DSL. Doing so is +method. Subsequent sections take a closer look at what you can do with those values.
| Important |
|---|---|
This section is valid only for Groovy DSL. Check out the +Section 8.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature. |
You can use regular expressions to write your requests in Contract DSL. Doing so is particularly useful when you want to indicate that a given response should be provided for requests that follow a given pattern. Also, you can use regular expressions when you need to use patterns and not exact values both for your test and your server side tests.
The following example shows how to use regular expressions to write a request:
org.springframework.cloud.contract.spec.Contract.make {
@@ -316,7 +618,7 @@ need to use patterns and not exact values both for your test and your server sid
url $(consumer(~/\/[0-9]{2}/), producer('/12'))
}
response {
- status 200
+ status OK()
body(
id: $(anyNumber()),
surname: $(
@@ -347,7 +649,7 @@ the provided regular expression. The following code shows an example:200
+ status OK()
body([
responseElement: $(producer(regex('[0-9]{7}')))
])
@@ -358,12 +660,18 @@ the provided regular expression. The following code shows an example:In the preceding example, the opposite side of the communication has the respective data
generated for request and response.
Spring Cloud Contract comes with a series of predefined regular expressions that you can
use in your contracts, as shown in the following example:
protected static final Pattern TRUE_OR_FALSE = Pattern.compile(/(true|false)/)
+protected static final Pattern ALPHA_NUMERIC = Pattern.compile('[a-zA-Z0-9]+')
protected static final Pattern ONLY_ALPHA_UNICODE = Pattern.compile(/[\p{L}]*/)
-protected static final Pattern NUMBER = Pattern.compile('-?\\d*(\\.\\d+)?')
+protected static final Pattern NUMBER = Pattern.compile('-?(\\d*\\.\\d+|\\d+)')
+protected static final Pattern INTEGER = Pattern.compile('-?(\\d+)')
+protected static final Pattern POSITIVE_INT = Pattern.compile('([1-9]\\d*)')
+protected static final Pattern DOUBLE = Pattern.compile('-?(\\d*\\.\\d+)')
+protected static final Pattern HEX = Pattern.compile('[a-fA-F0-9]+')
protected static final Pattern IP_ADDRESS = Pattern.compile('([01]?\\d\\d?|2[0-4]\\d|25[0-5])\\.([01]?\\d\\d?|2[0-4]\\d|25[0-5])\\.([01]?\\d\\d?|2[0-4]\\d|25[0-5])\\.([01]?\\d\\d?|2[0-4]\\d|25[0-5])')
protected static final Pattern HOSTNAME_PATTERN = Pattern.compile('((http[s]?|ftp):/)/?([^:/\\s]+)(:[0-9]{1,5})?')
protected static final Pattern EMAIL = Pattern.compile('[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,6}')
protected static final Pattern URL = UrlHelper.URL
+protected static final Pattern HTTPS_URL = UrlHelper.HTTPS_URL
protected static final Pattern UUID = Pattern.compile('[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}')
protected static final Pattern ANY_DATE = Pattern.compile('(\\d\\d\\d\\d)-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])')
protected static final Pattern ANY_DATE_TIME = Pattern.compile('([0-9]{4})-(1[0-2]|0[1-9])-(3[01]|0[1-9]|[12][0-9])T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])')
@@ -380,14 +688,30 @@ Pattern onlyAlphaUnicode() {
return ONLY_ALPHA_UNICODE
}
+Pattern alphaNumeric() {
+ return ALPHA_NUMERIC
+}
+
Pattern number() {
return NUMBER
}
+Pattern positiveInt() {
+ return POSITIVE_INT
+}
+
Pattern anyBoolean() {
return TRUE_OR_FALSE
}
+Pattern anInteger() {
+ return INTEGER
+}
+
+Pattern aDouble() {
+ return DOUBLE
+}
+
Pattern ipAddress() {
return IP_ADDRESS
}
@@ -404,6 +728,10 @@ Pattern url() {
return URL
}
+Pattern httpsUrl() {
+ return HTTPS_URL
+}
+
Pattern uuid(){
return UUID
}
@@ -453,7 +781,8 @@ Pattern nonBlank() {
message: "User not found by email = [${value(producer(regex(email())), consumer('not.existing@user.com'))}]"
)
}
-}
It is possible to provide optional parameters in your contract. However, you can provide +}
| Important |
|---|---|
This section is valid only for Groovy DSL. Check out the +Section 8.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature. |
It is possible to provide optional parameters in your contract. However, you can provide optional parameters only for the following:
- STUB side of the Request
- TEST side of the Response
The following example shows how to provide optional parameters:
org.springframework.cloud.contract.spec.Contract.make {
priority 1
request {
@@ -496,29 +825,30 @@ expression that must be present 0 or more times.If you use Spock for, the
"""
The following stub would also be generated:
''' { "request" : { - "url" : "/users/password", - "method" : "POST", - "bodyPatterns" : [ { - "matchesJsonPath" : "$[?(@.['email'] =~ /([a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\\\.[a-zA-Z]{2,6})?/)]" - }, { - "matchesJsonPath" : "$[?(@.['callback_url'] =~ /((http[s]?|ftp):\\\\/)\\\\/?([^:\\\\/\\\\s]+)(:[0-9]{1,5})?/)]" - } ], - "headers" : { - "Content-Type" : { - "equalTo" : "application/json" - } - } + "url" : "/users/password", + "method" : "POST", + "bodyPatterns" : [ { + "matchesJsonPath" : "$[?(@.['email'] =~ /([a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\\\.[a-zA-Z]{2,6})?/)]" + }, { + "matchesJsonPath" : "$[?(@.['callback_url'] =~ /((http[s]?|ftp):\\\\/)\\\\/?([^:\\\\/\\\\s]+)(:[0-9]{1,5})?/)]" + } ], + "headers" : { + "Content-Type" : { + "equalTo" : "application/json" + } + } }, "response" : { - "status" : 404, - "body" : "{\\"code\\":\\"123123\\",\\"message\\":\\"User not found by email == [not.existing@user.com]\\"}", - "headers" : { - "Content-Type" : "application/json" - } + "status" : 404, + "body" : "{\\"code\\":\\"123123\\",\\"message\\":\\"User not found by email == [not.existing@user.com]\\"}", + "headers" : { + "Content-Type" : "application/json" + } }, "priority" : 1 } -'''
You can define a method call that executes on the server side during the test. Such a +'''
| Important |
|---|---|
This section is valid only for Groovy DSL. Check out the +Section 8.5.7, “Dynamic Properties in the Matchers Sections” section for YAML examples of a similar feature. |
You can define a method call that executes on the server side during the test. Such a method can be added to the class defined as "baseClassForTests" in the configuration. The following code shows an example of the contract portion of the test case:
org.springframework.cloud.contract.spec.Contract.make {
request {
@@ -538,7 +868,7 @@ following code shows an example of the contract portion of the test case:'/api/12'), producer(regex('^/api/[0-9]{2}$'))),
correlationId: $(consumer('1223456'), producer(execute('isProperCorrelationId($it)')))
)
- status 200
+ status OK()
}
} The following code shows the base class portion of the test case:
abstract class BaseMockMvcSpec extends Specification { @@ -569,7 +899,7 @@ is applied for the whole body - not for parts of it.
The preceding example results in calling the hashCode() method in the request body.
It should resemble the following code:
// given: @@ -582,11 +912,17 @@ It should resemble the following code:// then: assertThat(response.statusCode()).isEqualTo(200);
The best situation is to provide fixed values, but sometimes you need to reference a
-request in your response. To do so, you can use the fromRequest() method, which lets
+request in your response.
If you’re writing contracts using Groovy DSL, you can use the fromRequest() method, which lets
you reference a bunch of elements from the HTTP request. You can use the following
options:
fromRequest().url(): Returns the request URL and query parameters.fromRequest().query(String key): Returns the first query parameter with a given name.fromRequest().query(String key, int index): Returns the nth query parameter with a given name.fromRequest().path(): Returns the full path.fromRequest().path(int index): Returns the nth path element.fromRequest().header(String key): Returns the first header with a given name.fromRequest().header(String key, int index): Returns the nth header with a given name.fromRequest().body(): Returns the full request body.fromRequest().body(String jsonPath): Returns the element from the request that -matches the JSON Path.
Consider the following contract:
Contract contractDsl = Contract.make {
+matches the JSON Path.If you’re using the YAML contract definition you have to use the
+Handlebars {{{ }}} notation with custom, Spring Cloud Contract
+ functions to achieve this.
{{{ request.url }}}: Returns the request URL and query parameters.{{{ request.query.key.[index] }}}: Returns the nth query parameter with a given name. +E.g. for keyfoo, first entry{{{ request.query.foo.[0] }}}{{{ request.path }}}: Returns the full path.{{{ request.path.[index] }}}: Returns the nth path element. E.g. +for first entry`{{{ request.path.[0] }}}{{{ request.headers.key }}}: Returns the first header with a given name.{{{ request.headers.key.[index] }}}: Returns the nth header with a given name.{{{ request.body }}}: Returns the full request body.{{{ jsonpath this 'your.json.path' }}}: Returns the element from the request that +matches the JSON Path. E.g. for json path$.foo-{{{ jsonpath this '$.foo' }}}
Consider the following contract:
Groovy DSL. +
Contract contractDsl = Contract.make {
request {
method 'GET'
url('/api/v1/xxxx') {
@@ -602,7 +938,7 @@ matches the JSON Path.Consider the following contract:
Consider the following contract:
Running a JUnit test generation leads to a test that resembles the following example:
// given:
+}+
YAML. +
request:
+ method: GET
+ url: /api/v1/xxxx
+ queryParameters:
+ foo:
+ - bar
+ - bar2
+ headers:
+ Authorization:
+ - secret
+ - secret2
+ body:
+ foo: bar
+ baz: 5
+response:
+ status: 200
+ headers:
+ Authorization: "foo {{{ request.headers.Authorization.0 }}} bar"
+ body:
+ url: "{{{ request.url }}}"
+ path: "{{{ request.path }}}"
+ pathIndex: "{{{ request.path.1 }}}"
+ param: "{{{ request.query.foo }}}"
+ paramIndex: "{{{ request.query.foo.1 }}}"
+ authorization: "{{{ request.headers.Authorization.0 }}}"
+ authorization2: "{{{ request.headers.Authorization.1 }}"
+ fullBody: "{{{ request.body }}}"
+ responseFoo: "{{{ jsonpath this '$.foo' }}}"
+ responseBaz: "{{{ jsonpath this '$.baz' }}}"
+ responseBaz2: "Bla bla {{{ jsonpath this '$.foo' }}} bla bla"+
Running a JUnit test generation leads to a test that resembles the following example:
// given: MockMvcRequestSpecification request = given() .header("Authorization", "secret") .header("Authorization", "secret2") @@ -697,7 +1065,9 @@ provide your own extensions, you can register an implementation of theorg.springframework.cloud.contract.verifier.dsl.wiremock.WireMockExtensionsinterface. Since we use the spring.factories extension approach, you can create an entry inMETA-INF/spring.factoriesfile similar to the following:org.springframework.cloud.contract.verifier.dsl.wiremock.WireMockExtensions=\ -org.springframework.cloud.contract.stubrunner.provider.wiremock.TestWireMockExtensionsThe following is an example of a custom extension:
TestWireMockExtensions.groovy. +org.springframework.cloud.contract.stubrunner.provider.wiremock.TestWireMockExtensions +org.springframework.cloud.contract.spec.ContractConverter=\ +org.springframework.cloud.contract.stubrunner.TestCustomYamlContractConverter
The following is an example of a custom extension:
TestWireMockExtensions.groovy.
package org.springframework.cloud.contract.verifier.dsl.wiremock import com.github.tomakehurst.wiremock.extension.Extension @@ -723,30 +1093,39 @@ org.springframework.cloud.contract.stubrunner.provider.wiremock.TestWireMockExte } }
| Important |
|---|---|
Remember to override the |