diff --git a/multi/multi__spring_cloud_contract_faq.html b/multi/multi__spring_cloud_contract_faq.html index d7e6aff236..bb0999e170 100644 --- a/multi/multi__spring_cloud_contract_faq.html +++ b/multi/multi__spring_cloud_contract_faq.html @@ -115,7 +115,7 @@ 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.0.0.BUILD-SNAPSHOT</version>
+ <version>2.0.0.RELEASE</version>
<relativePath />
</parent>
@@ -504,11 +504,141 @@ SCM repository, prefixed with the protocol. For example
"com.example:bookstore:0.0.1.RELEASE" )
With such a setup:
META-INF/groupId/artifactId/version/ folder
to find stub definitions and contracts. E.g. for com.example:foo:1.0.0 the path would be
-META-INF/com.example/foo/1.0.0/The generated tests all boil down to RestAssured in some form or fashion which relies on Apache HttpClient. HttpClient has a facility called wire logging which logs the entire request and response to HttpClient. Spring Boot has a logging common application property for doing this sort of thing, just add this to your application properties
logging.level.org.apache.http.wire=DEBUGWhen using Pact you can use the Pact Broker +to store and share Pact definitions. Starting from Spring Cloud Contract +2.0.0 one can fetch Pact files from the Pact Broker to generate +tests and stubs.
As a prerequisite the Pact Converter and Pact Stub Downloader
+are required. You have to add it via the spring-cloud-contract-pact dependency.
+You can read more about it in the Section 10.1.1, “Pact Converter” section.
![]() | Important |
|---|---|
Pact follows the Consumer Contract convention. That means +that the Consumer creates the Pact definitions first, then +shares the files with the Producer. Those expectations are generated +from the Consumer’s code and can break the Producer if the expectation +is not met. |
The consumer uses Pact framework to generate Pact files. The +Pact files are sent to the Pact Broker. An example of such +setup can be found here.
For the producer, to use the Pact files from the Pact Broker, we can reuse the
+same mechanism we use for external contracts. We route Spring Cloud Contract
+to use the Pact implementation via the URL that contains
+the pact:// protocol. It’s enough to pass the URL to the
+Pact Broker.
Maven. +
<plugin> + <groupId>org.springframework.cloud</groupId> + <artifactId>spring-cloud-contract-maven-plugin</artifactId> + <version>${spring-cloud-contract.version}</version> + <extensions>true</extensions> + <configuration> + <!-- Base class mappings etc. --> + + <!-- We want to pick contracts from a Git repository --> + <contractsRepositoryUrl>pact://http://localhost:8085</contractsRepositoryUrl> + + <!-- We reuse the contract dependency section to set up the path + to the folder that contains the contract definitions. In our case the + path will be /groupId/artifactId/version/contracts --> + <contractDependency> + <groupId>${project.groupId}</groupId> + <artifactId>${project.artifactId}</artifactId> + <!-- When + is passed, a latest tag will be applied when fetching pacts --> + <version>+</version> + </contractDependency> + + <!-- The contracts mode can't be classpath --> + <contractsMode>REMOTE</contractsMode> + </configuration> + <!-- Don't forget to add spring-cloud-contract-pact to the classpath! --> + <dependencies> + <dependency> + <groupId>org.springframework.cloud</groupId> + <artifactId>spring-cloud-contract-pact</artifactId> + <version>${spring-cloud-contract.version}</version> + </dependency> + </dependencies> +</plugin>
+
Gradle. +
buildscript {
+ repositories {
+ //...
+ }
+
+ dependencies {
+ // ...
+ // Don't forget to add spring-cloud-contract-pact to the classpath!
+ classpath "org.springframework.cloud:spring-cloud-contract-pact:${contractVersion}"
+ }
+}
+
+contracts {
+ // When + is passed, a latest tag will be applied when fetching pacts
+ contractDependency {
+ stringNotation = "${project.group}:${project.name}:+"
+ }
+ contractRepository {
+ repositoryUrl = "pact://http://localhost:8085"
+ }
+ // The mode can't be classpath
+ contractsMode = "REMOTE"
+ // Base class mappings etc.
+}+
With such a setup:
In the scenario where you don’t want to do Consumer Contract approach +(for every single consumer define the expectations) but you’d prefer +to do Producer Contracts (the producer provides the contracts and +publishes stubs), it’s enough to use Spring Cloud Contract with +Stub Runner option.
First, remember to add Stub Runner and Spring Cloud Contract Pact module +as test dependencies.
Maven. +
<dependencyManagement> + <dependencies> + <dependency> + <groupId>org.springframework.cloud</groupId> + <artifactId>spring-cloud-dependencies</artifactId> + <version>${spring-cloud.version}</version> + <type>pom</type> + <scope>import</scope> + </dependency> + </dependencies> +</dependencyManagement> + +<!-- Don't forget to add spring-cloud-contract-pact to the classpath! --> +<dependencies> + <!-- ... --> + <dependency> + <groupId>org.springframework.cloud</groupId> + <artifactId>spring-cloud-starter-contract-stub-runner</artifactId> + <scope>test</scope> + </dependency> + <dependency> + <groupId>org.springframework.cloud</groupId> + <artifactId>spring-cloud-contract-pact</artifactId> + <scope>test</scope> + </dependency> +</dependencies>
+
Gradle. +
dependencyManagement {
+ imports {
+ mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
+ }
+}
+
+dependencies {
+ //...
+ testCompile("org.springframework.cloud:spring-cloud-starter-contract-stub-runner")
+ // Don't forget to add spring-cloud-contract-pact to the classpath!
+ testCompile("org.springframework.cloud:spring-cloud-contract-pact")
+}+
Next, just pass the URL of the Pact Broker to repositoryRoot, prefixed
+with pact:// protocol. E.g. pact://http://localhost:8085
@RunWith(SpringRunner.class) +@SpringBootTest +@AutoConfigureStubRunner(stubsMode = StubRunnerProperties.StubsMode.REMOTE, + ids = "com.example:beer-api-producer-pact", + repositoryRoot = "pact://http://localhost:8085") +public class BeerControllerTest { + //Inject the port of the running stub + @StubRunnerPort("beer-api-producer-pact") int producerPort; + //... +}
With such a setup:
For more information about Pact support you can go to +the Section 10.7, “Using the Pact Stub Downloader” section.
The generated tests all boil down to RestAssured in some form or fashion which relies on Apache HttpClient. HttpClient has a facility called wire logging which logs the entire request and response to HttpClient. Spring Boot has a logging common application property for doing this sort of thing, just add this to your application properties
logging.level.org.apache.http.wire=DEBUGStarting from version 1.2.0 we turn on WireMock logging to
info and the WireMock notifier to being verbose. Now you will
exactly know what request was received by WireMock server and which
-matching response definition was picked.
To turn off this feature just bump WireMock logging to ERROR
logging.level.com.github.tomakehurst.wiremock=ERRORYou can use the mappingsOutputFolder property on @AutoConfigureStubRunner or StubRunnerRule
+matching response definition was picked.
To turn off this feature just bump WireMock logging to ERROR
logging.level.com.github.tomakehurst.wiremock=ERRORYou can use the mappingsOutputFolder property on @AutoConfigureStubRunner or StubRunnerRule
to dump all mappings per artifact id. Also the port at which the given stub server was
-started will be attached.
Yes! With version 1.2.0 we’ve added such a possibility. It’s enough to call file(…) method in the
+started will be attached.