From b924a5da97438fa23b7b2f0560708de1bb2ca147 Mon Sep 17 00:00:00 2001
From: buildmaster The preceding example uses Spring’s Apart from the default JUnit 4, you can instead use JUnit 5 or Spock tests, by setting the plugin
+respectively.) Since 2.1.0, it is also possible to use Here is an example of a test generated in Apart from the default JUnit 4, you can instead use JUnit 5 or Spock tests, by setting the plugin
You can now also generate WireMock scenarios based on the contracts, by including an
order number followed by an underscore at the beginning of the contract file names. The following example shows an auto-generated test in Spock for a messaging stub contract:MockMvc to run the tests. This is the default test
-mode for HTTP contracts. However, JAX-RX client and explicit HTTP invocations can also be
+mode for HTTP contracts. However, JAX-RS client and explicit HTTP invocations can also be
used. (To do so, change the testMode property of the plugin to JAX-RS or EXPLICIT,
-respectively.)RestAssuredWebTestClient`with Spring’s reactive `WebTestClient
+run under the hood. This is particularly recommended while working with Reactive, Web-Flux-based applications.
+In order to use WebTestClient set testMode to WEBTESTCLIENT.WEBTESTCLIENT test mode:[source,java,indent=0]
@Test
+ public void validate_shouldRejectABeerIfTooYoung() throws Exception {
+ // given:
+ WebTestClientRequestSpecification request = given()
+ .header("Content-Type", "application/json")
+ .body("{\"age\":10}");
+
+ // when:
+ WebTestClientResponse response = given().spec(request)
+ .post("/check");
+
+ // then:
+ assertThat(response.statusCode()).isEqualTo(200);
+ assertThat(response.header("Content-Type")).matches("application/json.*");
+ // and:
+ DocumentContext parsedJson = JsonPath.parse(response.getBody().asString());
+ assertThatJson(parsedJson).field("['status']").isEqualTo("NOT_OK");
+ }testFramework property to either JUNIT5 or Spock.![[Tip]](images/tip.png)
Tip [source,groovy,indent=0]
given:
ContractVerifierMessage inputMessage = contractVerifierMessaging.create(
diff --git a/multi/multi__spring_cloud_contract_verifier_setup.html b/multi/multi__spring_cloud_contract_verifier_setup.html
index ab2c443be2..8d838962e9 100644
--- a/multi/multi__spring_cloud_contract_verifier_setup.html
+++ b/multi/multi__spring_cloud_contract_verifier_setup.html
@@ -116,7 +116,7 @@ shown here:
contracts {
baseClassForTests = 'org.mycompany.tests'
generatedTestSourcesDir = project.file('src/generatedContract')
}execution definition, as shown he
<baseClassForTests>org.springframework.cloud.verifier.twitter.place.BaseMockMvcSpec</baseClassForTests>
</configuration>
</plugin>baseClassForTests’s package and from `packageWithBaseClasses.
If neither of these values are set, then the value is set to
diff --git a/multi/multi__spring_cloud_contract_wiremock.html b/multi/multi__spring_cloud_contract_wiremock.html
index 5ba211e421..44c3923880 100644
--- a/multi/multi__spring_cloud_contract_wiremock.html
+++ b/multi/multi__spring_cloud_contract_wiremock.html
@@ -162,8 +162,7 @@ Example:Spring REST Docs can be used to generate
documentation (for example in Asciidoctor format) for an HTTP API with Spring MockMvc
-or WebTestClient or
-Rest Assured. At the same time that you generate documentation for your API, you can also
+or WebTestClient or Rest Assured. At the same time that you generate documentation for your API, you can also
generate WireMock stubs by using Spring Cloud Contract WireMock. To do so, write your
normal REST Docs test cases and use @AutoConfigureRestDocs to have stubs be
automatically generated in the REST Docs output directory. The following code shows an
diff --git a/multi/multi__using_the_pluggable_architecture.html b/multi/multi__using_the_pluggable_architecture.html
index 620642f441..4cd749eac3 100644
--- a/multi/multi__using_the_pluggable_architecture.html
+++ b/multi/multi__using_the_pluggable_architecture.html
@@ -422,10 +422,10 @@ to clone the repository and use it as a source of contracts
to generate tests or stubs.
Either via environment variables, system properties, properties set inside the plugin or contracts repository configuration you can tweak the downloader’s behaviour. Below you can find the list of -properties
Table 10.1. SCM Stub Downloader properties
Type of a property | Name of the property | Description |
* * * | master | Which branch to checkout |
* * * | Git clone username | |
* * * | Git clone password | |
* * * | 10 | Number of attempts to push the commits to |
* * * | 1000 | Number of millis to wait between attempts to push the commits to |
Whenever the repositoryRoot starts with a Pact protocol
+properties
Table 10.1. SCM Stub Downloader properties
Type of a property | Name of the property | Description |
* * * | master | Which branch to checkout |
* * * | Git clone username | |
* * * | Git clone password | |
* * * | 10 | Number of attempts to push the commits to |
* * * | 1000 | Number of millis to wait between attempts to push the commits to |
Whenever the repositoryRoot starts with a Pact protocol
(starts with pact://), the stub downloader will try
to fetch the Pact contract definitions from the Pact Broker.
Whatever is set after pact:// will be parsed as the Pact Broker URL.
Either via environment variables, system properties, properties set 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 |
* * * | Host from URL passed to | What is the URL of Pact Broker |
* * * | Port from URL passed to | What is the port of Pact Broker |
* * * | Protocol from URL passed to | What is the protocol of Pact Broker |
* * * | Version of the stub, or | What tags should be used to fetch the stub |
* * * |
| What kind of authentication should be used to connect to the Pact Broker |
* * * | The username passed to | Username used to connect to the Pact Broker |
* * * | The password passed to | Password used to connect to the Pact Broker |
* * * | false | When |