groupid:artifactidcom.example:foo, com.example:bar.@StubRunnerPort("foo") int fooPort; @StubRunnerPort("com.example:bar") -int barPort;
Stub Runner can integrate with Spring Cloud.
For real life examples you can check the
The most important feature of Stub Runner Spring Cloud is the fact that it’s stubbing
DiscoveryClientRibbonServerList
that means that regardless of the fact whether you’re using Zookeeper, Consul, Eureka or anything else, you don’t need that in your tests. +int barPort;
Stub Runner can integrate with Spring Cloud.
For real life examples you can check the
The most important feature of Stub Runner Spring Cloud is the fact that it’s stubbing
DiscoveryClientRibbonServerList
that means that regardless of the fact whether you’re using Zookeeper, Consul, Eureka or anything else, you don’t need that in your tests.
We’re starting WireMock instances of your dependencies and we’re telling your application whenever you’re using Feign, load balanced RestTemplate
or DiscoveryClient directly, to call those stubbed servers instead of calling the real Service Discovery tool.
For example this test will pass
def 'should make service discovery work'() { expect: 'WireMocks are running' 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 06a5e4824c..a73e496f99 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,14 +10,14 @@ own integrations.
Before becoming Spring Cloud Contract, this project was called Accurest. It was created by Marcin Grzejszczak and Jakub Kubrynski -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.
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.
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 implementor of the service creates stubs that might have nothing to do with reality.
- You can go to production with passing tests and failing production.
To solve the aforementioned issues, Spring Cloud Contract Verifier with Stub Runner was created. The main idea is to give you very fast feedback, without the need to set up the whole world of microservices. If you work on stubs, then the only applications you need -are those that your application directly uses.
Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were +are those that your application directly uses.
Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were created by the service that you’re calling. Also, if you can use them, it means that they were tested against the producer’s side. In short, you can trust those stubs.
The main purposes of Spring Cloud Contract Verifier with Stub Runner are:
- To ensure that WireMock/Messaging stubs (used when developing the client) do exactly what the actual server-side implementation does.
- To promote ATDD method and Microservices architectural style.
- To provide a way to publish changes in contracts that are immediately visible on both
@@ -425,8 +425,8 @@ us. The current implementation of our system grants loans to everybody.
As sprint, we must develop a new feature: if a client wants to borrow too much money, then we mark the client as a fraud.
Technical remark - Fraud Detection has an
artifact-idofhttp-server, while Loan Issuance has an artifact-id ofhttp-client, and both have agroup-idofcom.example.Social remark - both client and server development teams need to communicate directly and -discuss changes while going through the process. CDC is all about communication.
The server -side code is available here and the +discuss changes while going through the process. CDC is all about communication.
The server +side code is available here and the client code here.
![[Tip]](images/tip.png)
Tip In this case, the producer owns the contracts. Physically, all the contract are in the producer’s repository.
If using the SNAPSHOT / Milestone / Release Candidate versions please add the following section to your build:
Maven. diff --git a/2.1.x/multi/multi__spring_cloud_contract_verifier_setup.html b/2.1.x/multi/multi__spring_cloud_contract_verifier_setup.html index 1afb2e5d91..82e32a106e 100644 --- a/2.1.x/multi/multi__spring_cloud_contract_verifier_setup.html +++ b/2.1.x/multi/multi__spring_cloud_contract_verifier_setup.html @@ -544,7 +544,7 @@ goal. Example:
</plugin>Under Section 10.6, “Using the SCM Stub Downloader” you can find all possible configuration options that you can pass either via the
<configuration><contractProperties>map, a system property -or an environment variable.If you see the following exception while using STS:
When you click on the error marker you should see something like this:
plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring- +or an environment variable.
If you see the following exception while using STS:
When you click on the error marker you should see something like this:
plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring- cloud-contract-maven-plugin:1.1.0.M1:convert failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145) at org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:331) at org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1362) at ... diff --git a/2.1.x/multi/multi__spring_cloud_contract_wiremock.html b/2.1.x/multi/multi__spring_cloud_contract_wiremock.html index 8ba9456064..cef802f7be 100644 --- a/2.1.x/multi/multi__spring_cloud_contract_wiremock.html +++ b/2.1.x/multi/multi__spring_cloud_contract_wiremock.html @@ -2,7 +2,7 @@
11. Spring Cloud Contract WireMock The Spring Cloud Contract WireMock modules let you use WireMock in a Spring Boot application. Check out the -samples +samples for more details.
If you have a Spring Boot application that uses Tomcat as an embedded server (which is the default with
spring-boot-starter-web), you can addspring-cloud-starter-contract-stub-runnerto your classpath and add@AutoConfigureWireMockin diff --git a/2.1.x/single/spring-cloud-contract.html b/2.1.x/single/spring-cloud-contract.html index 8209c27114..aadfc7f824 100644 --- a/2.1.x/single/spring-cloud-contract.html +++ b/2.1.x/single/spring-cloud-contract.html @@ -15,14 +15,14 @@ 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.
Before becoming Spring Cloud Contract, this project was called Accurest. It was created by Marcin Grzejszczak and Jakub Kubrynski -from (Codearte.
The
0.1.0release took place on 26 Jan 2015 and it became stable with1.0.0release on 29 Feb 2016.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.0release took place on 26 Jan 2015 and it became stable with1.0.0release on 29 Feb 2016.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 implementor of the service creates stubs that might have nothing to do with reality.
- You can go to production with passing tests and failing production.
To solve the aforementioned issues, Spring Cloud Contract Verifier with Stub Runner was created. The main idea is to give you very fast feedback, without the need to set up the whole world of microservices. If you work on stubs, then the only applications you need -are those that your application directly uses.
Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were +are those that your application directly uses.
Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were created by the service that you’re calling. Also, if you can use them, it means that they were tested against the producer’s side. In short, you can trust those stubs.
diff --git a/2.1.x/spring-cloud-contract.xml b/2.1.x/spring-cloud-contract.xml index 5ea8c70bd7..d1106df93a 100644 --- a/2.1.x/spring-cloud-contract.xml +++ b/2.1.x/spring-cloud-contract.xml @@ -56,7 +56,7 @@ from (Codearte.The main purposes of Spring Cloud Contract Verifier with Stub Runner are:
- To ensure that WireMock/Messaging stubs (used when developing the client) do exactly what the actual server-side implementation does.
- To promote ATDD method and Microservices architectural style.
- To provide a way to publish changes in contracts that are immediately visible on both
@@ -430,8 +430,8 @@ us. The current implementation of our system grants loans to everybody.
As sprint, we must develop a new feature: if a client wants to borrow too much money, then we mark the client as a fraud.
Technical remark - Fraud Detection has an
artifact-idofhttp-server, while Loan Issuance has an artifact-id ofhttp-client, and both have agroup-idofcom.example.Social remark - both client and server development teams need to communicate directly and -discuss changes while going through the process. CDC is all about communication.
The server -side code is available here and the +discuss changes while going through the process. CDC is all about communication.
The server +side code is available here and the client code here.
Tip In this case, the producer owns the contracts. Physically, all the contract are in the producer’s repository.
If using the SNAPSHOT / Milestone / Release Candidate versions please add the following section to your build:
Maven. @@ -927,7 +927,7 @@ It can be related to security issues where the consumers can’t clone the p contracts in a single place then you, as a producer, will know how many consumers you have and which consumer you will break with your local changes.
Let’s assume that we have a producer with coordinates
com.example:serverand 3 consumers:client1,client2,client3. Then in the repository with common contracts you would have the following setup -(which you can checkout here):├── com +(which you can checkout here):
├── com │ └── example │ └── server │ ├── client1 @@ -961,15 +961,15 @@ one to one to the contents of the repo.
Example of a
<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> - <version>2.2.0.BUILD-SNAPSHOT</version> + <version>2.1.3.RELEASE</version> <relativePath/> </parent> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.version>1.8</java.version> - <spring-cloud-contract.version>2.2.0.BUILD-SNAPSHOT</spring-cloud-contract.version> - <spring-cloud-release.version>Hoxton.BUILD-SNAPSHOT + <spring-cloud-contract.version>2.1.2.BUILD-SNAPSHOT</spring-cloud-contract.version> + <spring-cloud-release.version>Greenwich.BUILD-SNAPSHOT </spring-cloud-release.version> <excludeBuildFolders>true</excludeBuildFolders> </properties> @@ -2088,7 +2088,7 @@ goal. Example:</plugin>Under Section 10.6, “Using the SCM Stub Downloader” you can find all possible configuration options that you can pass either via the
<configuration><contractProperties>map, a system property -or an environment variable.If you see the following exception while using STS:
When you click on the error marker you should see something like this:
plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring- +or an environment variable.
If you see the following exception while using STS:
When you click on the error marker you should see something like this:
plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring- cloud-contract-maven-plugin:1.1.0.M1:convert failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145) at org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:331) at org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1362) at ... @@ -2699,8 +2699,8 @@ producer stubs.
The producer would setup the contr └── com.example └── beer-api-producer-restdocs └── nested - └── contract3.groovy
To achieve proper stub packaging.
Or using the Maven
assemblyplugin or -Gradle Jar task you have to create the following + └── contract3.groovyTo achieve proper stub packaging.
Or using the Maven
assemblyplugin or +Gradle Jar task you have to create the following structure in your stubs jar.└── META-INF └── com.example └── beer-api-producer-restdocs @@ -3106,7 +3106,7 @@ Value of the annotation can be thegroupid:artifactidcom.example:foo,com.example:bar.@StubRunnerPort("foo") int fooPort; @StubRunnerPort("com.example:bar") -int barPort;
Stub Runner can integrate with Spring Cloud.
For real life examples you can check the
The most important feature of
Stub Runner Spring Cloudis the fact that it’s stubbingDiscoveryClientRibbonServerList
that means that regardless of the fact whether you’re using Zookeeper, Consul, Eureka or anything else, you don’t need that in your tests. +int barPort;
Stub Runner can integrate with Spring Cloud.
For real life examples you can check the
The most important feature of
Stub Runner Spring Cloudis the fact that it’s stubbingDiscoveryClientRibbonServerList
that means that regardless of the fact whether you’re using Zookeeper, Consul, Eureka or anything else, you don’t need that in your tests. We’re starting WireMock instances of your dependencies and we’re telling your application whenever you’re using
Feign, load balancedRestTemplateorDiscoveryClientdirectly, to call those stubbed servers instead of calling the real Service Discovery tool.For example this test will pass
def 'should make service discovery work'() { expect: 'WireMocks are running' @@ -6603,7 +6603,7 @@ inside the plugin or contracts repository configuration you can tweak the downloader’s behaviour. Below you can find the list of properties
Table 10.2. SCM Stub Downloader properties
Name of a property
Default
Description
*
pactbroker.host(plugin prop)*
stubrunner.properties.pactbroker.host(system prop)*
STUBRUNNER_PROPERTIES_PACTBROKER_HOST(env prop)Host from URL passed to
repositoryRootWhat is the URL of Pact Broker
*
pactbroker.port(plugin prop)*
stubrunner.properties.pactbroker.port(system prop)*
STUBRUNNER_PROPERTIES_PACTBROKER_PORT(env prop)Port from URL passed to
repositoryRootWhat is the port of Pact Broker
*
pactbroker.protocol(plugin prop)*
stubrunner.properties.pactbroker.protocol(system prop)*
STUBRUNNER_PROPERTIES_PACTBROKER_PROTOCOL(env prop)Protocol from URL passed to
repositoryRootWhat is the protocol of Pact Broker
*
pactbroker.tags(plugin prop)*
stubrunner.properties.pactbroker.tags(system prop)*
STUBRUNNER_PROPERTIES_PACTBROKER_TAGS(env prop)Version of the stub, or
latestif version is+What tags should be used to fetch the stub
*
pactbroker.auth.scheme(plugin prop)*
stubrunner.properties.pactbroker.auth.scheme(system prop)*
STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_SCHEME(env prop)BasicWhat kind of authentication should be used to connect to the Pact Broker
*
pactbroker.auth.username(plugin prop)*
stubrunner.properties.pactbroker.auth.username(system prop)*
STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_USERNAME(env prop)The username passed to
contractsRepositoryUsername(maven) orcontractRepository.username(gradle)Username used to connect to the Pact Broker
*
pactbroker.auth.password(plugin prop)*
stubrunner.properties.pactbroker.auth.password(system prop)*
STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_PASSWORD(env prop)The password passed to
contractsRepositoryPassword(maven) orcontractRepository.password(gradle)Password used to connect to the Pact Broker
*
pactbroker.provider-name-with-group-id(plugin prop)*
stubrunner.properties.pactbroker.provider-name-with-group-id(system prop)*
STUBRUNNER_PROPERTIES_PACTBROKER_PROVIDER_NAME_WITH_GROUP_ID(env prop)false
When
true, the provider name will be a combination ofgroupId:artifactId. Iffalse, justartifactIdis useddiff --git a/2.1.x/spring-cloud-contract-maven-plugin/spock.html b/2.1.x/spring-cloud-contract-maven-plugin/spock.html index ca2eef1ca2..4499752e3a 100644 --- a/2.1.x/spring-cloud-contract-maven-plugin/spock.html +++ b/2.1.x/spring-cloud-contract-maven-plugin/spock.html @@ -371,7 +371,7 @@The Spring Cloud Contract WireMock modules let you use WireMock in a Spring Boot application. Check out the -samples +samples for more details.
If you have a Spring Boot application that uses Tomcat as an embedded server (which is the default with
spring-boot-starter-web), you can addspring-cloud-starter-contract-stub-runnerto your classpath and add@AutoConfigureWireMockin diff --git a/2.1.x/spring-cloud-contract-maven-plugin/index.html b/2.1.x/spring-cloud-contract-maven-plugin/index.html index 9cf74b2ec3..6662663793 100644 --- a/2.1.x/spring-cloud-contract-maven-plugin/index.html +++ b/2.1.x/spring-cloud-contract-maven-plugin/index.html @@ -361,10 +361,10 @@ examples of Maven plugin setup.diff --git a/2.1.x/spring-cloud-contract-maven-plugin/junit.html b/2.1.x/spring-cloud-contract-maven-plugin/junit.html index c0fc751141..f9b3a9ca0e 100644 --- a/2.1.x/spring-cloud-contract-maven-plugin/junit.html +++ b/2.1.x/spring-cloud-contract-maven-plugin/junit.html @@ -326,7 +326,7 @@Project source code
- +Project source code
- +- + Microservices Architecture - + Stubbed Services http-client , and both have agroup-id ofcom.example .Social remark - both client and server development teams need to communicate directly and discuss changes while going through the process. CDC is all about communication. -The server -side code is available here and the + The server +side code is available here and the client code here. In this case, the producer owns the contracts. Physically, all the contract are @@ -1588,7 +1588,7 @@ consumer you will break with your local changes. Repo structure Let’s assume that we have a producer with coordinates +(which you can checkout here):com.example:server and 3 consumers:client1 ,client2 ,client3 . Then in the repository with common contracts you would have the following setup -(which you can checkout here):├── com │ └── example │ └── server @@ -1626,15 +1626,15 @@ one to one to the contents of the repo. <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> - <version>2.2.0.BUILD-SNAPSHOT</version> + <version>2.1.3.RELEASE</version> <relativePath/> </parent> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.version>1.8</java.version> - <spring-cloud-contract.version>2.2.0.BUILD-SNAPSHOT</spring-cloud-contract.version> - <spring-cloud-release.version>Hoxton.BUILD-SNAPSHOT + <spring-cloud-contract.version>2.1.2.BUILD-SNAPSHOT</spring-cloud-contract.version> + <spring-cloud-release.version>Greenwich.BUILD-SNAPSHOT </spring-cloud-release.version> <excludeBuildFolders>true</excludeBuildFolders> </properties> @@ -3521,7 +3521,7 @@ or an environment variable. - + STS Exception To achieve proper stub packaging. -Or using the Maven assembly plugin or -Gradle Jar task you have to create the following +Or using the Maven assembly plugin or +Gradle Jar task you have to create the following structure in your stubs jar.└── META-INF └── com.example @@ -5136,10 +5136,10 @@ int barPort; For real life examples you can check the - producer app sample +producer app sample - consumer app sample +consumer app sample @@ -10346,7 +10346,7 @@ properties Spring Cloud Contract WireMock The Spring Cloud Contract WireMock modules let you use WireMock in a Spring Boot application. Check out the -samples +samples for more details. If you have a Spring Boot application that uses Tomcat as an embedded server (which is the default with spring-boot-starter-web ), you can add