diff --git a/2.1.x/multi/multi__spring_cloud_contract_faq.html b/2.1.x/multi/multi__spring_cloud_contract_faq.html
index c7601cec52..863cdd094f 100644
--- a/2.1.x/multi/multi__spring_cloud_contract_faq.html
+++ b/2.1.x/multi/multi__spring_cloud_contract_faq.html
@@ -67,7 +67,7 @@ for time and UUID are simplified and most likely invalid but we want to keep thi
body: "bar"
])
}
-}![[Important]](images/important.png) | Important |
|---|
Please read the Groovy docs related to JSON to understand how to
+} 3.4 How to do Stubs versioning?Let’s try to answer a question what versioning really means. If you’re referring to the API version then there are
different approaches. - use Hypermedia, links and do not version your API by any means
- pass versions through headers / urls
I will not try to answer a question which approach is better. Whatever suits your needs and allows you to generate
business value should be picked. Let’s assume that you do version your API. In that case you should provide as many contracts as many versions you support.
diff --git a/2.1.x/multi/multi__spring_cloud_contract_stub_runner.html b/2.1.x/multi/multi__spring_cloud_contract_stub_runner.html
index 668ecc65ad..fcf0d6b529 100644
--- a/2.1.x/multi/multi__spring_cloud_contract_stub_runner.html
+++ b/2.1.x/multi/multi__spring_cloud_contract_stub_runner.html
@@ -761,7 +761,7 @@ the Stub Runner server. It will be available at port 8750<
}As you can see we want to start a Stub Runner Boot server @EnableStubRunnerServer, enable Eureka client @EnableEurekaClient
and we want to have the stub runner feature turned on @AutoConfigureStubRunner. Now let’s assume that we want to start this application so that the stubs get automatically registered.
We can do it by running the app java -jar ${SYSTEM_PROPS} stub-runner-boot-eureka-example.jar where
- ${SYSTEM_PROPS} would contain the following list of properties * -Dstubrunner.repositoryRoot=https://repo.spring.io/snapshots (1)
+ ${SYSTEM_PROPS} would contain the following list of properties * -Dstubrunner.repositoryRoot=https://repo.spring.io/snapshot (1)
* -Dstubrunner.cloud.stubbed.discovery.enabled=false (2)
* -Dstubrunner.ids=org.springframework.cloud.contract.verifier.stubs:loanIssuance,org.
* springframework.cloud.contract.verifier.stubs:fraudDetectionServer,org.springframework.
diff --git a/2.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html b/2.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html
index 263549d427..06a5e4824c 100644
--- a/2.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html
+++ b/2.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html
@@ -10,7 +10,7 @@ own integrations. Acceptance tests (in JUnit 4, JUnit 5
of the API is compliant with the contract (server tests). A full test is generated by
Spring Cloud Contract Verifier.2.2 Why a Contract Verifier?Assume that we have a system consisting of multiple microservices: If we wanted to test the application in top left corner to determine whether it can
+from (Codearte. The 0.1.0 release took place on 26 Jan 2015 and it became stable with 1.0.0 release on 29 Feb 2016. 2.2 Why a Contract Verifier?Assume that we have a system consisting of multiple microservices: If we wanted to test the application in top left corner to determine whether it can
communicate with other services, we could do one of two things: - Deploy all microservices and perform end-to-end tests.
- Mock other microservices in unit/integration tests.
Both have their advantages but also a lot of disadvantages. Deploy all microservices and perform end to end tests Advantages: - Simulates production.
- Tests real communication between services.
Disadvantages: - To test one microservice, we have to deploy 6 microservices, a couple of databases,
etc.
- The environment where the tests run is locked for a single suite of tests (nobody else
would be able to run the tests in the meantime).
- They take a long time to run.
- The feedback comes very late in the process.
- They are extremely hard to debug.
Mock other microservices in unit/integration tests Advantages: - They provide very fast feedback.
- They have no infrastructure requirements.
Disadvantages: |
The previously shown contract is an agreement between two sides that:
Once you are ready to check the API in practice in the integration tests, you need to
install the stubs locally.
Add the Spring Cloud Contract Verifier plugin.
We can add either a Maven or a Gradle plugin. In this example, you see how to add Maven.
@@ -742,7 +742,7 @@ make the name of the base test class. In our case, the contracts were placed und
src/test/resources/contracts/fraud. Since you do not have two packages starting from
the contracts folder, pick only one, which should be fraud. Add the Base suffix and
capitalize fraud. That gives you the FraudBase test class name.
All the generated tests extend that class. Over there, you can set up your Spring Context
-or whatever is necessary. In this case, use Rest Assured MVC to
+or whatever is necessary. In this case, use Rest Assured MVC to
start the server side FraudDetectionController.
: https://repo.spring.io/libs-snapshot
That’s it!
The best way to add dependencies is to use the proper starter dependency.
For stub-runner, use spring-cloud-starter-stub-runner. When you use a plugin, add
spring-cloud-starter-contract-verifier.
Here are some resources related to Spring Cloud Contract Verifier and Stub Runner. Note
that some may be outdated, because the Spring Cloud Contract Verifier project is under
-constant development.
2.7.1 Spring Cloud Contract video
You can check out the video from the Warsaw JUG about Spring Cloud Contract:
You can find some samples at
+constant development.
2.7.1 Spring Cloud Contract video
You can check out the video from the Warsaw JUG about Spring Cloud Contract:
You can find some samples at
samples.
![[Tip]](images/tip.png)