diff --git a/2.0.x/multi/multi__customization.html b/2.0.x/multi/multi__customization.html index 3522c8d4ec..6e067f360c 100644 --- a/2.0.x/multi/multi__customization.html +++ b/2.0.x/multi/multi__customization.html @@ -1,6 +1,6 @@ - 9. Customization
9. Customization
Prev   Next

9. Customization

[Important]Important

This section is valid only for Groovy DSL

You can customize the Spring Cloud Contract Verifier by extending the DSL, as shown in + 9. Customization

9. Customization
Prev   Next

9. Customization

[Important]Important

This section is valid only for Groovy DSL

You can customize the Spring Cloud Contract Verifier by extending the DSL, as shown in the remainder of this section.

9.1 Extending the DSL

You can provide your own functions to the DSL. The key requirement for this feature is to maintain the static compatibility. Later in this document, you can see examples of:

  • Creating a JAR with reusable classes.
  • Referencing of these classes in the DSLs.

You can find the full example here.

9.1.1 Common JAR

The following examples show three classes that can be reused in the DSLs.

PatternUtils contains functions used by both the consumer and the producer.

package com.example;
@@ -214,4 +214,4 @@ then:
 			contentType(applicationJson())
 		}
 	}
-}
Prev   Next
8. Contract DSL Home 10. Using the Pluggable Architecture
\ No newline at end of file +}
Prev   Next
8. Contract DSL Home 10. Using the Pluggable Architecture
\ No newline at end of file diff --git a/2.0.x/multi/multi__spring_cloud_contract_faq.html b/2.0.x/multi/multi__spring_cloud_contract_faq.html index bee66294b6..cf5fcb1d51 100644 --- a/2.0.x/multi/multi__spring_cloud_contract_faq.html +++ b/2.0.x/multi/multi__spring_cloud_contract_faq.html @@ -45,7 +45,7 @@ sides of the communication. You can pass the values:

Either via the

or using the $() method

$(consumer(...), producer(...))
 $(stub(...), test(...))
-$(client(...), server(...))

You can read more about this in the ??? section.

Calling value() or $() tells Spring Cloud Contract that you will be passing a dynamic value. +$(client(...), server(...))

You can read more about this in the Chapter 8, Contract DSL section.

Calling value() or $() tells Spring Cloud Contract that you will be passing a dynamic value. Inside the consumer() method you pass the value that should be used on the consumer side (in the generated stub). Inside the producer() method you pass the value that should be used on the producer side (in the generated test).

[Tip]Tip

If on one side you have passed the regular expression and you haven’t passed the other, then the other side will get auto-generated.

Most often you will use that method together with the regex helper method. E.g. consumer(regex('[0-9]{10}')).

To sum it up the contract for the aforementioned scenario would look more or less like this (the regular expression @@ -82,7 +82,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 will you break with your local changes.

3.5.1 Repo structure

Let’s assume that we have a producer with coordinates 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
+(which you can checkout here):
├── com
 │   └── example
 │       └── server
 │           ├── client1
@@ -115,14 +115,14 @@ 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.3.RELEASE</version>
+		<version>2.0.4.RELEASE</version>
 		<relativePath />
 	</parent>
 
 	<properties>
 		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 		<java.version>1.8</java.version>
-		<spring-cloud-contract.version>2.1.0.BUILD-SNAPSHOT</spring-cloud-contract.version>
+		<spring-cloud-contract.version>2.0.2.BUILD-SNAPSHOT</spring-cloud-contract.version>
 		<spring-cloud-release.version>Finchley.BUILD-SNAPSHOT</spring-cloud-release.version>
 		<excludeBuildFolders>true</excludeBuildFolders>
 	</properties>
@@ -399,7 +399,7 @@ build.dependsOn(
 Artifactory or Nexus. Starting from Spring Cloud Contract version 2.0.0 we provide
 mechanisms to store contracts and stubs in a SCM repository. Currently the
 only supported SCM is Git.
The repository would have to the following setup
-(which you can checkout here):
.
+(which you can checkout here):
.
 └── META-INF
     └── com.example
         └── beer-api-producer-git
@@ -515,11 +515,11 @@ 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.

3.7.1 Pact Consumer

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.

3.7.2 Producer

For the producer, to use the Pact files from the Pact Broker, we can reuse the +setup can be found here.

3.7.2 Producer

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. An example of such setup can be found here.

Maven.  +Pact Broker. An example of such setup can be found here.

Maven.  

<plugin>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-contract-maven-plugin</artifactId>
@@ -582,7 +582,7 @@ contracts {
 (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. An example of such setup can be found here.
First, remember to add Stub Runner and Spring Cloud Contract Pact module
+Stub Runner option. An example of such setup can be found here.
First, remember to add Stub Runner and Spring Cloud Contract Pact module
 as test dependencies.
Maven. 
 
<dependencyManagement>
     <dependencies>
diff --git a/2.0.x/multi/multi__spring_cloud_contract_stub_runner.html b/2.0.x/multi/multi__spring_cloud_contract_stub_runner.html
index c8f3a9b83e..0fd3eb29f7 100644
--- a/2.0.x/multi/multi__spring_cloud_contract_stub_runner.html
+++ b/2.0.x/multi/multi__spring_cloud_contract_stub_runner.html
@@ -1,6 +1,6 @@
 
       
-   6. Spring Cloud Contract Stub Runner
6. Spring Cloud Contract Stub Runner
Prev   Next
6. Spring Cloud Contract Stub Runner
One of the issues that you might encounter while using Spring Cloud Contract Verifier is
+   6. Spring Cloud Contract Stub Runner
6. Spring Cloud Contract Stub Runner
Prev   Next
6. Spring Cloud Contract Stub Runner
One of the issues that you might encounter while using Spring Cloud Contract Verifier is
 passing the generated WireMock JSON stubs from the server side to the client side (or to
 various clients). The same takes place in terms of client-side generation for messaging.
Copying the JSON files and setting the client side for messaging manually is out of the
 question. That is why we introduced Spring Cloud Contract Stub Runner. It can
@@ -732,4 +732,4 @@ $ curl -H "Conte
 $ curl -X GET http://localhost:9876/api/books
 # You will receive contents of the JSON
[Important]Important
If you want use the stubs that you have built locally, on your host,
 then you should pass the environment variable -e STUBRUNNER_STUBS_MODE=LOCAL and mount
-the volume of your local m2 -v "${HOME}/.m2/:/root/.m2:ro"
Prev   Next
5. Spring Cloud Contract Verifier Messaging Home 7. Stub Runner for Messaging
\ No newline at end of file +the volume of your local m2 -v "${HOME}/.m2/:/root/.m2:ro"

Prev   Next
5. Spring Cloud Contract Verifier Messaging Home 7. Stub Runner for Messaging
\ No newline at end of file diff --git a/2.0.x/multi/multi__spring_cloud_contract_verifier_introduction.html b/2.0.x/multi/multi__spring_cloud_contract_verifier_introduction.html index 2b5f69a466..4c640f4bd8 100644 --- a/2.0.x/multi/multi__spring_cloud_contract_verifier_introduction.html +++ b/2.0.x/multi/multi__spring_cloud_contract_verifier_introduction.html @@ -9,14 +9,14 @@ produced by Spring Cloud Contract Verifier.
  • Messaging r Integration, Spring Cloud Stream, Spring AMQP, and Apache Camel. You can also set your own integrations.
  • Acceptance tests (in JUnit or Spock) are used to verify if server-side implementation of the API is compliant with the contract (server tests). A full test is generated by -Spring Cloud Contract Verifier.

    • 2.1 Why a Contract Verifier?

    Assume that we have a system consisting of multiple microservices:

    Microservices Architecture

    2.1.1 Testing issues

    If we wanted to test the application in top left corner to determine whether it can +Spring Cloud Contract Verifier.

    2.1 Why a Contract Verifier?

    Assume that we have a system consisting of multiple microservices:

    Microservices Architecture

    2.1.1 Testing issues

    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.

    Stubbed Services

    Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were +are those that your application directly uses.

    Stubbed Services

    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.

    2.2 Purposes

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

    7. Stub Runner for Messaging

    Stub Runner can run the published stubs in memory. It can integrate with the following frameworks:

    • Spring Integration
    • Spring Cloud Stream
    • Spring AMQP

    It also provides entry points to integrate with any other solution on the market.

    [Important]Important

    If you have multiple frameworks on the classpath Stub Runner will need to define which one should be used. Let’s assume that you have both AMQP, Spring Cloud Stream and Spring Integration on the classpath. Then you need to set stubrunner.stream.enabled=false and stubrunner.integration.enabled=false. @@ -3218,10 +3218,10 @@ classpath. Remember to annotate your test class with @Auto <queue/> </channel> -</beans:beans>

    These examples lend themselves to three scenarios:

    Scenario 1 (no input message)

    To trigger a message via the return_book_1 label, use the StubTigger interface, as +</beans:beans>

    These examples lend themselves to three scenarios:

    Scenario 1 (no input message)

    To trigger a message via the return_book_1 label, use the StubTigger interface, as follows:

    stubFinder.trigger('return_book_1')

    To listen to the output of the message sent to output:

    Message<?> receivedMessage = messaging.receive('outputTest')

    The received message would pass the following assertions:

    receivedMessage != null
 assertJsons(receivedMessage.payload)
-receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 2 (output triggered by input)

    Since the route is set for you, you can send a message to the output +receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 2 (output triggered by input)

    Since the route is set for you, you can send a message to the output destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'input')

    To listen to the output of the message sent to output:

    Message<?> receivedMessage = messaging.receive('outputTest')

    The received message passes the following assertions:

    receivedMessage != null
 assertJsons(receivedMessage.payload)
 receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the input destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    7.3 Stub Runner Stream

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to @@ -3390,7 +3390,7 @@ definition is matched and invoked with the contract message.

    ConnectionFactory.
    To disable the mocked ConnectionFactory, set the following property:
 stubrunner.amqp.mockConnection=false
    stubrunner:
   amqp:
-    mockConnection: false

    8. Contract DSL

    Spring Cloud Contract supports out of the box 2 types of DSL. One written in + mockConnection: false

    8. Contract DSL

    Spring Cloud Contract supports out of the box 2 types of DSL. One written in Groovy and one written in YAML.

    If you decide to write the contract in Groovy, do not be alarmed if you have not used Groovy before. Knowledge of the language is not really needed, as the Contract DSL uses only a tiny subset of it (only literals, method calls and closures). Also, the DSL is statically diff --git a/2.0.x/spring-cloud-contract.xml b/2.0.x/spring-cloud-contract.xml index b1f606ff7f..17cc346a01 100644 --- a/2.0.x/spring-cloud-contract.xml +++ b/2.0.x/spring-cloud-contract.xml @@ -53,7 +53,7 @@ Spring Cloud Contract Verifier. - + Microservices Architecture @@ -128,7 +128,7 @@ are those that your application directly uses. - + Stubbed Services @@ -707,8 +707,8 @@ we mark the client as a fraud. Issuance has an artifact-id of http-client, and both have a group-id of com.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 @@ -994,7 +994,7 @@ of an identifier or a timestamp, you need not hardcode a value. You want to allo different ranges of values. To enable ranges of values, you can set regular expressions matching those values for the consumer side. You can provide the body by means of either a map notation or String with interpolations. -Consult the section for more information. We highly recommend using the map notation! +Consult the section for more information. We highly recommend using the map notation! You must understand the map notation in order to set up contracts. Please read the Groovy docs regarding JSON. @@ -1513,7 +1513,7 @@ consumer will you break with your local changes. Repo structure Let’s assume that we have a producer with coordinates 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): +(which you can checkout here): ├── com │   └── example │   └── server @@ -1550,14 +1550,14 @@ one to one to the contents of the repo. <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> - <version>2.0.3.RELEASE</version> + <version>2.0.4.RELEASE</version> <relativePath /> </parent> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.version>1.8</java.version> - <spring-cloud-contract.version>2.1.0.BUILD-SNAPSHOT</spring-cloud-contract.version> + <spring-cloud-contract.version>2.0.2.BUILD-SNAPSHOT</spring-cloud-contract.version> <spring-cloud-release.version>Finchley.BUILD-SNAPSHOT</spring-cloud-release.version> <excludeBuildFolders>true</excludeBuildFolders> </properties> @@ -1940,7 +1940,7 @@ Artifactory or Nexus. Starting from Spring Cloud Contract version 2.0.0 we provi mechanisms to store contracts and stubs in a SCM repository. Currently the only supported SCM is Git. The repository would have to the following setup -(which you can checkout here): +(which you can checkout here): . └── META-INF └── com.example @@ -2153,7 +2153,7 @@ is not met. Pact Consumer 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. +setup can be found here.

    Producer @@ -2161,7 +2161,7 @@ setup can be found here. +Pact Broker. An example of such setup can be found here. Maven @@ -2248,7 +2248,7 @@ contracts { (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. An example of such setup can be found here. +Stub Runner option. An example of such setup can be found here. First, remember to add Stub Runner and Spring Cloud Contract Pact module as test dependencies. @@ -3304,7 +3304,7 @@ or an environment variable. - + STS Exception @@ -3440,7 +3440,7 @@ name of scenario1 and the three following steps: More details about WireMock scenarios can be found at -http://wiremock.org/stateful-behaviour.html +http://wiremock.org/docs/stateful-behaviour/ Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.
    @@ -5320,7 +5320,7 @@ the volume of your local m2 -v "${HOME}/.m2/:/root/.m2:ro"
    - + Stub Runner for Messaging Stub Runner can run the published stubs in memory. It can integrate with the following frameworks: @@ -5537,7 +5537,7 @@ follows: assertJsons(receivedMessage.payload) receivedMessage.headers.get('BOOK-NAME') == 'foo' -
    +
    Scenario 2 (output triggered by input) Since the route is set for you, you can send a message to the output destination: @@ -5836,7 +5836,7 @@ configure a mock ConnectionFactory.
    - + Contract DSL Spring Cloud Contract supports out of the box 2 types of DSL. One written in Groovy and one written in YAML.