Version: 1.0.3.BUILD-SNAPSHOT
diff --git a/1.0.x/spring-cloud-contract.html b/1.0.x/spring-cloud-contract.html
index 2bbfa12d95..9388f40a8e 100644
--- a/1.0.x/spring-cloud-contract.html
+++ b/1.0.x/spring-cloud-contract.html
@@ -1599,36 +1599,38 @@ public void shouldBeRejectedDueToAbnormalLoanAmount() {
package contracts
org.springframework.cloud.contract.spec.Contract.make {
- request { // (1)
- method 'PUT' // (2)
- url '/fraudcheck' // (3)
- body([ // (4)
- clientId: value(consumer(regex('[0-9]{10}'))),
- loanAmount: 99999
- ])
- headers { // (5)
- contentType("application/vnd.fraud.v1+json")
- }
- }
- response { // (6)
- status 200 // (7)
- body([ // (8)
- fraudCheckStatus: "FRAUD",
- rejectionReason: "Amount too high"
- ])
- headers { // (9)
- contentType("application/vnd.fraud.v1+json")
- }
- }
+ request { // (1)
+ method 'PUT' // (2)
+ url '/fraudcheck' // (3)
+ body([ // (4)
+ clientId: $(regex('[0-9]{10}')),
+ loanAmount: 99999
+ ])
+ headers { // (5)
+ contentType('application/vnd.fraud.v1+json')
+ }
+ }
+ response { // (6)
+ status 200 // (7)
+ body([ // (8)
+ fraudCheckStatus: "FRAUD",
+ rejectionReason: "Amount too high"
+ ])
+ headers { // (9)
+ contentType('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.
+(timestamps, database ids etc.), one can parametrize those entries. If you wrap your field's
+ value in a `$(...)` or `value(...)` and provide a dynamic value of a field then
+ the concrete value will be generated for you. If you want to be really explicit about
+ which side gets which value you can do that by using the `value(consumer(...), producer(...))` notation.
+ 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: