diff --git a/1.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html b/1.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html index b969f16e0d..bc5444f6c0 100644 --- a/1.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html +++ b/1.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html @@ -8,63 +8,7 @@ to set up the whole world of microservices. If you work on stubs then the only a tested against the producer’s side. In other words - you can trust those stubs.

2.2 Purposes

The main purposes of Spring Cloud Contract Verifier with Stub Runner are:

[Important]Important

Spring Cloud Contract Verifier’s purpose is NOT to start writing business features in the contracts. Let’s assume that we have a business use case of fraud check. If a user can be a fraud for 100 different reasons, we would assume that you would create 2 contracts. One for the positive and one for the negative fraud case. -Contract tests are used to test contracts between applications and not to simulate full behaviour.

2.3 How

2.3.1 Define the contract

As consumers we need to define what exactly we want to achieve. We need to formulate our expectations. That’s why we write the following contract.

Let’s assume that we’d like to send the request containing the id of the client and the amount he wants to borrow from us. We’d like to send it to the /fraudcheck url via the PUT method.

package contracts
-
-org.springframework.cloud.contract.spec.Contract.make {
-	request { // (1)
-		method 'PUT' // (2)
-		url '/fraudcheck' // (3)
-		body([ // (4)
-			   "client.id": $(regex('[0-9]{10}')),
-			   loanAmount: 99999
-		])
-		headers { // (5)
-			contentType('application/json')
-		}
-	}
-	response { // (6)
-		status 200 // (7)
-		body([ // (8)
-			   fraudCheckStatus: "FRAUD",
-			   "rejection.reason": "Amount too high"
-		])
-		headers { // (9)
-			contentType('application/json')
-		}
-	}
-}
-
-/*
-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/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/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/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/json.*`
- */

2.3.2 Client Side

Spring Cloud Contract will generate stubs, which you can use during client side testing. +Contract tests are used to test contracts between applications and not to simulate full behaviour.

2.3 How

2.3.1 Define the contract

As consumers we need to define what exactly we want to achieve. We need to formulate our expectations. That’s why we write the following contract.

Let’s assume that we’d like to send the request containing the id of the client and the amount he wants to borrow from us. We’d like to send it to the /fraudcheck url via the PUT method.

Unresolved directive in verifier_introduction.adoc - include::https://raw.githubusercontent.com/spring-cloud/spring-cloud-contract/master/samples/standalone/dsl/http-server/src/test/resources/contracts/fraud/shouldMarkClientAsFraud.groovy[]

2.3.2 Client Side

Spring Cloud Contract will generate stubs, which you can use during client side testing. You will have a WireMock instance / Messaging route up and running that simulates the service Y. You would like to feed that instance with a proper stub definition.

At some point in time you need to send a request to the Fraud Detection service.

ResponseEntity<FraudServiceResponse> response =
 		restTemplate.exchange("http://localhost:" + port + "/fraudcheck", HttpMethod.PUT,
diff --git a/1.1.x/single/spring-cloud-contract.html b/1.1.x/single/spring-cloud-contract.html
index 53ba8d6bbf..c6ac565b12 100644
--- a/1.1.x/single/spring-cloud-contract.html
+++ b/1.1.x/single/spring-cloud-contract.html
@@ -12,63 +12,7 @@ to set up the whole world of microservices. If you work on stubs then the only a
 tested against the producer’s side. In other words - you can trust those stubs.

2.2 Purposes

The main purposes of Spring Cloud Contract Verifier with Stub Runner are:

[Important]Important

Spring Cloud Contract Verifier’s purpose is NOT to start writing business features in the contracts. Let’s assume that we have a business use case of fraud check. If a user can be a fraud for 100 different reasons, we would assume that you would create 2 contracts. One for the positive and one for the negative fraud case. -Contract tests are used to test contracts between applications and not to simulate full behaviour.

2.3 How

2.3.1 Define the contract

As consumers we need to define what exactly we want to achieve. We need to formulate our expectations. That’s why we write the following contract.

Let’s assume that we’d like to send the request containing the id of the client and the amount he wants to borrow from us. We’d like to send it to the /fraudcheck url via the PUT method.

package contracts
-
-org.springframework.cloud.contract.spec.Contract.make {
-	request { // (1)
-		method 'PUT' // (2)
-		url '/fraudcheck' // (3)
-		body([ // (4)
-			   "client.id": $(regex('[0-9]{10}')),
-			   loanAmount: 99999
-		])
-		headers { // (5)
-			contentType('application/json')
-		}
-	}
-	response { // (6)
-		status 200 // (7)
-		body([ // (8)
-			   fraudCheckStatus: "FRAUD",
-			   "rejection.reason": "Amount too high"
-		])
-		headers { // (9)
-			contentType('application/json')
-		}
-	}
-}
-
-/*
-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/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/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/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/json.*`
- */

2.3.2 Client Side

Spring Cloud Contract will generate stubs, which you can use during client side testing. +Contract tests are used to test contracts between applications and not to simulate full behaviour.

2.3 How

2.3.1 Define the contract

As consumers we need to define what exactly we want to achieve. We need to formulate our expectations. That’s why we write the following contract.

Let’s assume that we’d like to send the request containing the id of the client and the amount he wants to borrow from us. We’d like to send it to the /fraudcheck url via the PUT method.

Unresolved directive in verifier_introduction.adoc - include::https://raw.githubusercontent.com/spring-cloud/spring-cloud-contract/master/samples/standalone/dsl/http-server/src/test/resources/contracts/fraud/shouldMarkClientAsFraud.groovy[]

2.3.2 Client Side

Spring Cloud Contract will generate stubs, which you can use during client side testing. You will have a WireMock instance / Messaging route up and running that simulates the service Y. You would like to feed that instance with a proper stub definition.

At some point in time you need to send a request to the Fraud Detection service.

ResponseEntity<FraudServiceResponse> response =
 		restTemplate.exchange("http://localhost:" + port + "/fraudcheck", HttpMethod.PUT,
diff --git a/1.1.x/spring-cloud-contract.xml b/1.1.x/spring-cloud-contract.xml
index a2e1db269c..7aa96182f8 100644
--- a/1.1.x/spring-cloud-contract.xml
+++ b/1.1.x/spring-cloud-contract.xml
@@ -154,63 +154,7 @@ Contract tests are used to test contracts between applications and not to simula
 Define the contract
 As consumers we need to define what exactly we want to achieve. We need to formulate our expectations. That’s why we write the following contract.
 Let’s assume that we’d like to send the request containing the id of the client and the amount he wants to borrow from us. We’d like to send it to the /fraudcheck url via the PUT method.
-package contracts
-
-org.springframework.cloud.contract.spec.Contract.make {
-	request { // (1)
-		method 'PUT' // (2)
-		url '/fraudcheck' // (3)
-		body([ // (4)
-			   "client.id": $(regex('[0-9]{10}')),
-			   loanAmount: 99999
-		])
-		headers { // (5)
-			contentType('application/json')
-		}
-	}
-	response { // (6)
-		status 200 // (7)
-		body([ // (8)
-			   fraudCheckStatus: "FRAUD",
-			   "rejection.reason": "Amount too high"
-		])
-		headers { // (9)
-			contentType('application/json')
-		}
-	}
-}
-
-/*
-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/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/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/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/json.*`
- */
+Unresolved directive in verifier_introduction.adoc - include::https://raw.githubusercontent.com/spring-cloud/spring-cloud-contract/master/samples/standalone/dsl/http-server/src/test/resources/contracts/fraud/shouldMarkClientAsFraud.groovy[]
 
 

 Client Side