Samples for Spring Cloud Contract project
Java Shell Groovy JavaScript HTML
Clone or download
Permalink
Failed to load latest commit information.
.circleci Trying to fix circleci Jun 18, 2018
.mvn/wrapper Bumped libs Jun 20, 2017
beer_contracts Updated sc-contract to 2.0.1 Jul 19, 2018
common Bumped boot to 2.0.3 Jun 18, 2018
consumer Bumped boot to 2.0.3 Jun 18, 2018
consumer_pact Bumped boot to 2.0.3 Jun 18, 2018
consumer_pact_stubrunner Bumped boot to 2.0.3 Jun 18, 2018
consumer_with_discovery Bumped boot to 2.0.3 Jun 18, 2018
consumer_with_restdocs Bumped boot to 2.0.3 Jun 18, 2018
consumer_with_stubs_per_consumer Fixed compilation issues Jul 16, 2018
contract_git Added git downloader Mar 31, 2018
docker Trying without nginx: Apr 2, 2018
docs Updated sc-contract to 2.0.1 Jul 19, 2018
gradle/wrapper Made things work Nov 15, 2017
producer Updated sc-contract to 2.0.1 Jul 19, 2018
producer_advanced Updated sc-contract to 2.0.1 Jul 19, 2018
producer_pact Updated sc-contract to 2.0.1 Jul 19, 2018
producer_webflux Updated sc-contract to 2.0.1 Jul 19, 2018
producer_with_dsl_restdocs Updated sc-contract to 2.0.1 Jul 19, 2018
producer_with_external_contracts Updated sc-contract to 2.0.1 Jul 19, 2018
producer_with_git Updated sc-contract to 2.0.1 Jul 19, 2018
producer_with_restdocs Updated sc-contract to 2.0.1 Jul 19, 2018
producer_with_stubs_per_consumer Updated sc-contract to 2.0.1 Jul 19, 2018
producer_yaml Updated sc-contract to 2.0.1 Jul 19, 2018
scripts Added DSL with restdocs, swagger and swagger client generator (#29) May 24, 2018
.gitignore Copying test reports Apr 24, 2018
LICENSE.txt Initial commit Nov 9, 2016
README.adoc Pact broker (#26) Apr 2, 2018
build.gradle Forgotten to save Apr 24, 2018
gradlew Workshop (#7) May 12, 2017
gradlew.bat Workshop (#7) May 12, 2017
mvnw Initial commit Nov 9, 2016
mvnw.cmd Initial commit Nov 9, 2016
pom.xml Added DSL with restdocs, swagger and swagger client generator (#29) May 24, 2018

README.adoc

CircleCI

Spring Cloud Contract samples

This repository contains the consumer and the producer applications to use with Spring Cloud Contract project.

It contains several important branches. master where we test against the latest versions of Spring Cloud Contract, and x.x.x where we test against x.x.x version of Spring Cloud Contract.

This repository shows examples of

  • storing contracts on the producer side

  • storing contracts in a common repo

  • passing stubs via Rest docs

  • integration with Pact and Pact Broker

Both for REST and Messaging. Built with Maven and Gradle. Also some additional Spring Cloud Contract plugin configuration is present.

These samples were used in the following presentation. It might help to use the samples.

You can also go through the Spring Cloud Contract Workshops to learn how to use the tool by example.

Projects

Common

Contains the JAR with common classes used in the contracts on the producer side.

Beer_contracts

Contains the repo with all contracts for all applications. It can be used when you want to store all contracts in a single place.

Producer

The producer application contains contracts for both REST and messaging communication. From these contracts tests and stubs will be generated.

The producer in the contract also uses features like usage of common libraries, different combination of dynamic properties.

It also uses scenario based contracts. That means that the produced stubs are stateful.

Producer_yaml

The same as Producer but uses YAML

Producer_advanced

Contains more advanced examples of Spring Cloud Contract usage.

Producer_with_external_contracts

The producer application that downloads its contracts for both REST and messaging communication, from the Beer-contracts JAR. From these contracts tests and stubs will be generated.

Producer_with_restdocs

The producer application that uses both contracts and Spring Cloud Contract WireMock with RESTDocs. Contracts are used for messaging but the HTTP stubs are created via REST Docs tests.

Producer_with_stubs_per_consumer

The producer application stores the contracts in such way that every consumer has its own, delegated folder. Then on the consumer side by turning on the stubs per consumer feature only respective stubs for the given consumer will be used.

Consumer

The consumer application is using the stubs of the producer for both rest and messaging.

It also contains the consumer side of the stateful scenario case. By calling the same endpoint a couple of times we get different responses due to changing state.

Consumer_with_discovery

The consumer application is using the stubs of the producer for rest. It sends requests via a load balanced rest template. In the tests Spring Cloud Contract stubs out any discovery service infrastructure.

Consumer_with_restdocs

The consumer application is using the stubs of the producer for both rest and messaging. The stubs come from the test compile dependency of the producer.

Consumer_with_stubs_per_consumer

The consumer application that has the stub of the HTTP server get fed with stubs that lay under proper folder in the reused JAR.

Docker

Contains docker setup for Pact Broker

Consumer_pact

Since Pact works around the idea of consumer contract, the contract definitions (the Pact files), are defined and set up on the consumer side. Then the Pact files get uploaded to the Pact Broker

Producer_pact

This project connects to the Pact Broker to retrieve the list of Pact files. From the files tests and WireMock stubs are generated.

Consumer_pact_stubrunner

If one wants to do producer contracts with Pact Broker, one can upload the pacts from a consumer (which actually can be the producer) and then all the other consumers, can use Spring Cloud Contract Stub Runner to run stubs of the producer.

How to build it?

You can run Maven from the root folder once the "common" module has been installed. So from a clean checkout:

(cd common; ../mvnw clean install)
./mvnw clean install -Ptest

(or ./scripts/runMavenBuild.sh). Then you can build normally

./mvnw clean install

The order should be as follows

  • common

  • beer-contracts

  • producer

  • producer_advanced

  • producer_with_external_contracts

  • producer_with_stubs_per_consumer

  • consumer

  • consumer_with_discovery

  • producer_with_restdocs

  • consumer_with_restdocs

  • consumer_with_stubs_per_consumer

If the order is different then your apps will blow up most likely due to missing stubs.

You can also go to each of the projects and run Gradle wrapper:

./gradlew clean build publishToMavenLocal

How to test it?

You can run the script

./scripts/runAcceptanceTests.sh