Updated docs

2016-07-15 15:27:39 +02:00
parent d0f7572872
commit 1f86138517
9 changed files with 94 additions and 93 deletions
--- a/README.adoc
+++ b/README.adoc
@@ -20,7 +20,7 @@ Currently we support Jetty, Native WireMock server, Tomcat and Undertow.

 === Spring Cloud Contract Verifier

-== Introduction
+=== Introduction

 IMPORTANT: http://codearte.github.io/accurest[The documentation to the deprecated Accurest project in version 1.1.0 is available here.]

@@ -37,13 +37,13 @@ Full test is generated by Spring Cloud Contract Verifier.

 Spring Cloud Contract Verifier moves TDD to the level of software architecture.

-=== Why?
+==== Why?

 Let us assume that we have a system comprising of multiple microservices:

 image::https://raw.githubusercontent.com/spring-cloud/spring-cloud-contract/master/docs/src/main/asciidoc/images/Deps.png[Microservices Architecture]

-==== Testing issues
+===== Testing issues

 If we wanted to test the application in top left corner if it can communicate with other services then we could do one of two things:

@@ -92,7 +92,7 @@ Spring Cloud Contract Verifier gives you the certainty that the stubs that you'r
 tested against the producer's side. In other words - you can trust those stubs.


-=== Purposes
+==== Purposes

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

@@ -101,7 +101,7 @@ The main purposes of Spring Cloud Contract Verifier with Stub Runner are:
  - to provide a way to publish changes in contracts that are immediately visible on both sides,
  - to generate boilerplate test code used on the server side.

-=== Client Side
+==== Client Side

 During the tests you want to have a Wiremock instance / Messaging route up and running that simulates the service Y.
 You would like to feed that instance with a proper stub definition. That stub definition would need
@@ -110,7 +110,7 @@ to be valid and should also be reusable on the server side.
 __Summing it up:__ On this side, in the stub definition, you can use patterns for request stubbing and you need exact
 values for responses.

-=== Server Side
+==== Server Side

 Being a service Y since you are developing your stub, you need to be sure that it's actually resembling your
 concrete implementation. You can't have a situation where your stub acts in one way and your application on
@@ -122,7 +122,7 @@ that your application behaves in the same way as you define in your stub.
 __Summing it up:__ On this side, in the stub definition, you need exact values as request and can use patterns/methods
 for response verification.

-=== Step by step guide to CDC
+==== Step by step guide to CDC

 Let's take an example of Fraud Detection and Loan Issuance process. Let's assume that the Loan Issuance is a client to the
 Fraud Detection server. Let's assume that we have to write a new feature (if a client wants too borrow too much money then
@@ -279,7 +279,7 @@ return new FraudCheckResult(FraudCheckStatus.OK, NO_REASON);
 }
 ----

-=== Dependencies
+==== Dependencies

 Spring Cloud Contract Verifier and Stub Runner are using the following libraries

@@ -287,12 +287,12 @@ Spring Cloud Contract Verifier and Stub Runner are using the following libraries
 - https://github.com/jayway/JsonPath[Jayway JSONPath]
 - https://github.com/marcingrzejszczak/jsonassert[JSONAssert from Marcin Grzejszczak]

-=== Additional links
+==== Additional links

 Below you can find some resources related to Spring Cloud Contract Verifier and Stub Runner. Note that some can be outdated since the Spring Cloud Contract Verifier project
 is under constant development.

-==== Videos
+===== Videos

 *Marcin Grzejszczak and Jakub Kubryński talking about Spring Cloud Contract Verifier*

@@ -312,17 +312,17 @@ video::130779882[vimeo]

 https://vimeo.com/130779882[click here to see the video]

-==== Readings
+===== Readings

 - http://www.slideshare.net/MarcinGrzejszczak/stick-to-the-rules-consumer-driven-contracts-201507-confitura[Slides from Marcin Grzejszczak's talk about Accurest]
 - http://toomuchcoding.com/blog/categories/accurest/[Accurest related articles from Marcin Grzejszczak's blog]
 - http://toomuchcoding.com/blog/categories/spring-cloud-contract/[Spring Cloud Contract related articles from Marcin Grzejszczak's blog]

-=== Samples
+==== Samples

 Here you can find some https://github.com/spring-cloud/spring-cloud-contract/tree/master/samples/[samples].

-=== Why use Spring Cloud Contract Verifier and not X ?
+==== Why use Spring Cloud Contract Verifier and not X ?

 For the time being Spring Cloud Contract Verifier is a JVM based tool. So it could be your first pick when you're already creating
 software for the JVM. This project has a lot of really interesting features but especially quite a few of them definitely make
@@ -335,7 +335,7 @@ Spring Cloud Contract Verifier stand out on the "market" of Consumer Driven Cont
 - Stub Runner functionality - the stubs are automatically downloaded at runtime from Nexus / Artifactory
 - Spring Cloud integration - no discovery service is needed for integration tests

-== Links
+=== Links

 Here you can find interesting links related to Spring Cloud Contract Verifier:

--- a/docs/src/main/asciidoc/spring-cloud-contract.adoc
+++ b/docs/src/main/asciidoc/spring-cloud-contract.adoc
@@ -1,4 +1,5 @@
 :toc: left
+:toclevels: 4

 = Spring Cloud Contract

--- a/docs/src/main/asciidoc/verifier/contract.adoc
+++ b/docs/src/main/asciidoc/verifier/contract.adoc
@@ -1,4 +1,4 @@
-== Contract DSL
+=== Contract DSL

 IMPORTANT: Remember that inside the contract file you have to provide the fully qualified name to
 the `Contract` class and the `make` static import i.e. `org.springframework.cloud.spec.Contract.make { ... }`.
@@ -22,7 +22,7 @@ Not all features of the DSL are used in example above. If you didn't find what y

 > You can easily compile Contracts to WireMock stubs mapping using standalone maven command: `mvn org.springframework.cloud:spring-cloud-contract-maven-plugin:convert`.

-=== Limitations
+==== Limitations

 WARNING: Spring Cloud Contract Verifier doesn't support XML properly. Please use JSON or help us implement this feature.

@@ -32,7 +32,7 @@ WARNING: The support for the verification of size of JSON arrays is experimental
 the value of a system property `spring.cloud.contract.verifier.assert.size` equal to `true`. By default this feature is set to
 `false`. You can also provide the `assertJsonSize` property in the plugin configuration.

-=== HTTP Top-Level Elements
+==== HTTP Top-Level Elements

 Following methods can be called in the top-level closure of a contract definition. Request and response are mandatory, priority is optional.

@@ -41,7 +41,7 @@ Following methods can be called in the top-level closure of a contract definitio
 include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract/verifier/builder/ContractHttpDocsSpec.groovy[tags=http_dsl,indent=0]
 ----

-=== Request
+==== Request

 HTTP protocol requires only **method and address** to be specified in a request. The same information is mandatory in request definition of the Contract.

@@ -86,7 +86,7 @@ include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract
 include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract/verifier/builder/ContractHttpDocsSpec.groovy[tags=bodyAsXml,indent=0]
 ----

-=== Response
+==== Response

 Minimal response must contain **HTTP status code**.

@@ -97,7 +97,7 @@ include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract

 Besides status response may contain **headers** and **body**, which are specified the same way as in the request (see previous paragraph).

-=== Regular expressions
+==== Regular expressions
 You can use regular expressions to write your requests in Contract DSL. It is particularly useful when you want to indicate that a given response
 should be provided for requests that follow a given pattern. Also, you can use it when you need to use patterns and not exact values both
 for your test and your server side tests.
@@ -120,7 +120,7 @@ include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract
 In this example for request and response the opposite side of the communication will have the respective data generated.


-=== Passing optional parameters
+==== Passing optional parameters

 It is possible to provide optional parameters in your contract. It's only possible to have optional parameter for the:

@@ -150,25 +150,25 @@ and the following stub:
 include::{verifier_root_path}/spring-cloud-contract-verifier-converters/src/test/groovy/org/springframework/cloud/contract/verifier/wiremock/DslToWireMockClientConverterSpec.groovy[tags=wiremock,indent=0]
 ----

-=== Executing custom methods on server side
+==== Executing custom methods on server side
 It is also possible to define a method call to be executed on the server side during the test. Such a method can be added to the class defined as "baseClassForTests"
 in the configuration. Please see the examples below:

-==== Contract DSL
+===== Contract DSL

 [source,groovy,indent=0]
 ----
 include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract/verifier/builder/ContractHttpDocsSpec.groovy[tags=method,indent=0]
 ----

-==== Base Mock Spec
+===== Base Mock Spec

 [source,groovy,indent=0]
 ----
 include::{plugins_path}/spring-cloud-contract-gradle-plugin/src/test/resources/functionalTest/bootSimple/src/test/groovy/org/springframework/cloud/contract/verifier/twitter/places/BaseMockMvcSpec.groovy[tags=base_class,indent=0]
 ----

-=== JAX-RS support
+==== JAX-RS support
 Starting with release 0.8.0 we support JAX-RS 2 Client API. Base class needs to define `protected WebTarget webTarget` and server initialization, right now the only option how to test JAX-RS API is to start a web server.

 Request with a body needs to have a content type set otherwise `application/octet-stream` is going to be used.
@@ -177,7 +177,7 @@ In order to use JAX-RS mode, use the following settings:

 [source,groovy,indent=0]
 ----
-testMode == 'JAXRSCLIENT'
+testMode === 'JAXRSCLIENT'
 ----

 Example of a test API generated:
@@ -187,11 +187,11 @@ Example of a test API generated:
 include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract/verifier/builder/JaxRsClientMethodBuilderSpec.groovy[tags=jaxrs,indent=0]
 ----

-=== Messaging Top-Level Elements
+==== Messaging Top-Level Elements

 The DSL for messaging looks a little bit different than the one that focuses on HTTP.

-==== Output triggered by a method
+===== Output triggered by a method

 The output message can be triggered by calling a method (e.g. a Scheduler was started and a message was sent)

@@ -203,7 +203,7 @@ include::{samples_path}/samples-messaging-integration/src/test/groovy/com/exampl
 In this case the output message will be sent to `output` if a method called `bookReturnedTriggered` will be executed. In the message *publisher's* side
 we will generate a test that will call that method to trigger the message. On the *consumer* side you can use the `some_label` to trigger the message.

-==== Output triggered by a message
+===== Output triggered by a message

 The output message can be triggered by receiving a message.

@@ -216,7 +216,7 @@ In this case the output message will be sent to `output` if a proper message wil
 we will generate a test that will send the input message to the defined destination. On the *consumer* side you can either send a message to the input
 destination or use the `some_label` to trigger the message.

-==== Consumer / Producer
+===== Consumer / Producer

 In HTTP you have a notion of `client`/`stub and `server`/`test` notation. You can use them also in messaging but we're providing also the `consumer` and `produer` methods
 as presented below (note you can use either `$` or `value` methods to provide `consumer` and `producer` parts)
--- a/docs/src/main/asciidoc/verifier/introduction.adoc
+++ b/docs/src/main/asciidoc/verifier/introduction.adoc
@@ -1,4 +1,4 @@
-== Introduction
+=== Introduction

 IMPORTANT: http://codearte.github.io/accurest[The documentation to the deprecated Accurest project in version 1.1.0 is available here.]

@@ -15,13 +15,13 @@ Full test is generated by Spring Cloud Contract Verifier.

 Spring Cloud Contract Verifier moves TDD to the level of software architecture.

-=== Why?
+==== Why?

 Let us assume that we have a system comprising of multiple microservices:

 image::https://raw.githubusercontent.com/spring-cloud/spring-cloud-contract/master/docs/src/main/asciidoc/images/Deps.png[Microservices Architecture]

-==== Testing issues
+===== Testing issues

 If we wanted to test the application in top left corner if it can communicate with other services then we could do one of two things:

@@ -70,7 +70,7 @@ Spring Cloud Contract Verifier gives you the certainty that the stubs that you'r
 tested against the producer's side. In other words - you can trust those stubs.


-=== Purposes
+==== Purposes

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

@@ -79,7 +79,7 @@ The main purposes of Spring Cloud Contract Verifier with Stub Runner are:
  - to provide a way to publish changes in contracts that are immediately visible on both sides,
  - to generate boilerplate test code used on the server side.

-=== Client Side
+==== Client Side

 During the tests you want to have a Wiremock instance / Messaging route up and running that simulates the service Y.
 You would like to feed that instance with a proper stub definition. That stub definition would need
@@ -88,7 +88,7 @@ to be valid and should also be reusable on the server side.
 __Summing it up:__ On this side, in the stub definition, you can use patterns for request stubbing and you need exact
 values for responses.

-=== Server Side
+==== Server Side

 Being a service Y since you are developing your stub, you need to be sure that it's actually resembling your
 concrete implementation. You can't have a situation where your stub acts in one way and your application on
@@ -100,7 +100,7 @@ that your application behaves in the same way as you define in your stub.
 __Summing it up:__ On this side, in the stub definition, you need exact values as request and can use patterns/methods
 for response verification.

-=== Step by step guide to CDC
+==== Step by step guide to CDC

 Let's take an example of Fraud Detection and Loan Issuance process. Let's assume that the Loan Issuance is a client to the
 Fraud Detection server. Let's assume that we have to write a new feature (if a client wants too borrow too much money then
@@ -198,7 +198,7 @@ include::https://raw.githubusercontent.com/spring-cloud/spring-cloud-contract/ma
 }
 ----

-=== Dependencies
+==== Dependencies

 Spring Cloud Contract Verifier and Stub Runner are using the following libraries

@@ -206,12 +206,12 @@ Spring Cloud Contract Verifier and Stub Runner are using the following libraries
 - https://github.com/jayway/JsonPath[Jayway JSONPath]
 - https://github.com/marcingrzejszczak/jsonassert[JSONAssert from Marcin Grzejszczak]

-=== Additional links
+==== Additional links

 Below you can find some resources related to Spring Cloud Contract Verifier and Stub Runner. Note that some can be outdated since the Spring Cloud Contract Verifier project
 is under constant development.

-==== Videos
+===== Videos

 *Marcin Grzejszczak and Jakub Kubryński talking about Spring Cloud Contract Verifier*

@@ -231,17 +231,17 @@ video::130779882[vimeo]

 https://vimeo.com/130779882[click here to see the video]

-==== Readings
+===== Readings

 - http://www.slideshare.net/MarcinGrzejszczak/stick-to-the-rules-consumer-driven-contracts-201507-confitura[Slides from Marcin Grzejszczak's talk about Accurest]
 - http://toomuchcoding.com/blog/categories/accurest/[Accurest related articles from Marcin Grzejszczak's blog]
 - http://toomuchcoding.com/blog/categories/spring-cloud-contract/[Spring Cloud Contract related articles from Marcin Grzejszczak's blog]

-=== Samples
+==== Samples

 Here you can find some https://github.com/spring-cloud/spring-cloud-contract/tree/master/samples/[samples].

-=== Why use Spring Cloud Contract Verifier and not X ?
+==== Why use Spring Cloud Contract Verifier and not X ?

 For the time being Spring Cloud Contract Verifier is a JVM based tool. So it could be your first pick when you're already creating
 software for the JVM. This project has a lot of really interesting features but especially quite a few of them definitely make
--- a/docs/src/main/asciidoc/verifier/links.adoc
+++ b/docs/src/main/asciidoc/verifier/links.adoc
@@ -1,4 +1,4 @@
-== Links
+=== Links

 Here you can find interesting links related to Spring Cloud Contract Verifier:

--- a/docs/src/main/asciidoc/verifier/messaging.adoc
+++ b/docs/src/main/asciidoc/verifier/messaging.adoc
@@ -1,9 +1,9 @@
-== Spring Cloud Contract Verifier Messaging
+=== Spring Cloud Contract Verifier Messaging

 Spring Cloud Contract Verifier allows you to verify your application that uses messaging as means of communication.
 All of our integrations are working with Spring but you can also set one yourself.

-=== Integrations
+==== Integrations

 You can use one of the three integration configurations:

@@ -25,7 +25,7 @@ testCompile "org.springframework.cloud:spring-cloud-contract-verifier-integratio
 testCompile "org.springframework.cloud:spring-cloud-contract-verifier-stream:${verifierVersion}"
 ----

-=== Manual Integration
+==== Manual Integration

 The `spring-cloud-contract-verifier-messaging-core` module contains 3 main interfaces:

@@ -44,7 +44,7 @@ You have to provide as a dependency the `spring-cloud-contract-verifier-messagin
 testCompile "org.springframework.cloud:spring-cloud-contract-verifier-messaging-core:${verifierVersion}"
 ----

-=== Publisher side test generation
+==== Publisher side test generation

 Having the `input` or `outputMessage` sections in your DSL will result in creation of tests on the publisher's side. By default
 JUnit tests will be created, however there is also a possibility to create Spock tests.
@@ -56,7 +56,7 @@ inside the application (e.g. scheduler)
 - Scenario 2: the input message triggers an output message
 - Scenario 3: the input message is consumed and there is no output message

-==== Scenario 1 (no input message)
+===== Scenario 1 (no input message)

 For the given contract:

@@ -79,7 +79,7 @@ And the following Spock test would be created:
 include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract/verifier/builder/MessagingMethodBodyBuilderSpec.groovy[tags=trigger_method_test]
 ----

-==== Scenario 2 (output triggered by input)
+===== Scenario 2 (output triggered by input)

 For the given contract:

@@ -102,7 +102,7 @@ And the following Spock test would be created:
 include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract/verifier/builder/MessagingMethodBodyBuilderSpec.groovy[tags=trigger_message_spock]
 ----

-==== Scenario 3 (no output message)
+===== Scenario 3 (no output message)

 For the given contract:

@@ -125,14 +125,14 @@ And the following Spock test would be created:
 include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract/verifier/builder/MessagingMethodBodyBuilderSpec.groovy[tags=trigger_no_output_spock]
 ----

-=== Consumer Stub Side generation
+==== Consumer Stub Side generation

 Unlike the HTTP part - in Messaging we need to publish the Groovy DSL inside the JAR with a stub. Then it's parsed on the consumer side
 and proper stubbed routes are created.

 For more infromation please consult the Stub Runner Messaging sections.

-==== Gradle Setup
+===== Gradle Setup

 Example of Spring Cloud Contract Verifier Gradle setup:

@@ -141,6 +141,6 @@ Example of Spring Cloud Contract Verifier Gradle setup:
 include::{plugins_path}/spring-cloud-contract-gradle-plugin/src/test/resources/functionalTest/scenarioProject/build.gradle[tags=jar_setup,indent=0]
 ----

-==== Maven Setup
+===== Maven Setup

 Example of Maven can be found in the https://github.com/spring-cloud/spring-cloud-contract/[Spring Cloud Contract Verifier README]
--- a/docs/src/main/asciidoc/verifier/rest.adoc
+++ b/docs/src/main/asciidoc/verifier/rest.adoc
@@ -1,12 +1,12 @@
-== Spring Cloud Contract Verifier HTTP
+=== Spring Cloud Contract Verifier HTTP

-=== Gradle Project
+==== Gradle Project

-==== Prerequisites
+===== Prerequisites

 In order to use Spring Cloud Contract Verifier with WireMock you have to use gradle or maven plugin.

-===== Add gradle plugin
+====== Add gradle plugin

 [source,groovy,indent=0]
 ----
@@ -29,7 +29,7 @@ dependencies {
 }
 ----

-====== Snapshot versions
+======= Snapshot versions

 Add the additional snapshot repository to your build.gradle to use snapshot versions which are automatically uploaded after every successful build:

@@ -42,7 +42,7 @@ repositories {
 }
 ----

-===== Add maven plugin
+====== Add maven plugin

 [source,xml,indent=0]
 ----
@@ -64,7 +64,7 @@ repositories {

 Read more: https://cloud.spring.io/spring-cloud-contract/spring-cloud-contract-maven-plugin/[spring-cloud-contract-maven-plugin]

-===== Add stubs
+====== Add stubs

 By default Spring Cloud Contract Verifier is looking for stubs in `src/test/resources/contracts` directory.

@@ -83,11 +83,11 @@ Spring Cloud Contract Verifier will create test class `defaultBasePackage.MyServ
 - `shouldCreateUser()`
 - `shouldReturnUser()`

-==== Run plugin
+===== Run plugin

 Plugin registers itself to be invoked before `check` task. You have nothing to do as long as you want it to be part of your build process. If you just want to generate tests please invoke `generateContractTests` task.

-==== Default setup
+===== Default setup

 Default Gradle Plugin setup creates the following Gradle part of the build (it's a pseudocode)

@@ -129,7 +129,7 @@ publishing {
 }
 ----

-==== Configure plugin
+===== Configure plugin

 To change default configuration just add `contractVerifier` snippet to your Gradle config

@@ -142,7 +142,7 @@ contractVerifier {
 }
 ----

-===== Configuration options
+====== Configuration options

 - **testMode** - defines mode for acceptance tests. By default MockMvc which is based on Spring's MockMvc. It can also be changed to **JaxRsClient** or to **Explicit** for real HTTP calls.
 - **imports** - array with imports that should be included in generated tests (for example ['org.myorg.Matchers']). By default empty array []
@@ -156,7 +156,7 @@ contractVerifier {
 - **stubsOutputDir** - dir where the generated WireMock stubs from Groovy DSL should be placed
 - **targetFramework** - the target test framework to be used; currently Spock and JUnit are supported with JUnit being the default framework

-===== Base class for tests
+====== Base class for tests

 When using Spring Cloud Contract Verifier in default MockMvc you need to create a base specification for all generated acceptance tests. In this class you need to point to endpoint which should be verified.

@@ -168,7 +168,7 @@ include::{plugins_path}/spring-cloud-contract-gradle-plugin/src/test/resources/f
 In case of using `Explicit` mode, you can use base class to initialize the whole tested app similarly as in regular integration tests. In case of `JAXRSCLIENT` mode this base class
 should also contain `protected WebTarget webTarget` field, right now the only option to test JAX-RS API is to start a web server.

-==== Invoking generated tests
+===== Invoking generated tests

 To ensure that provider side is complaint with defined contracts, you need to invoke:

@@ -177,7 +177,7 @@ To ensure that provider side is complaint with defined contracts, you need to in
 ./gradlew generateContractTests test
 ----

-==== Spring Cloud Contract Verifier on consumer side
+===== Spring Cloud Contract Verifier on consumer side

 In consumer service you need to configure Spring Cloud Contract Verifier plugin in exactly the same way as in case of provider. If you don't want to use Stub Runner then you need to copy contracts stored in
 `src/test/resources/contracts` and generate WireMock json stubs using:
@@ -210,17 +210,17 @@ class LoanApplicationServiceSpec extends Specification {
   when:
 	LoanApplicationResult loanApplication == sut.loanApplication(application)
   then:
-	loanApplication.loanApplicationStatus === LoanApplicationStatus.LOAN_APPLIED
-	loanApplication.rejectionReason === null
+	loanApplication.loanApplicationStatus == LoanApplicationStatus.LOAN_APPLIED
+	loanApplication.rejectionReason == null
 }
 }
 ----

 Underneath LoanApplication makes a call to FraudDetection service. This request is handled by Wiremock server configured using stubs generated by Spring Cloud Contract Verifier.

-=== Using in your Maven project
+==== Using in your Maven project

-==== Add maven plugin
+===== Add maven plugin

 [source,xml,indent=0]
 ----
@@ -241,7 +241,7 @@ Underneath LoanApplication makes a call to FraudDetection service. This request

 Read more: https://cloud.spring.io/spring-cloud-contract/spring-cloud-contract-maven-plugin/[spring-cloud-contract-maven-plugin]

-==== Add stubs
+===== Add stubs

 By default Spring Cloud Contract Verifier is looking for stubs in `src/test/resources/contracts` directory.
 Directory containing stub definitions is treated as a class name, and each stub definition is treated as a single test.
@@ -258,11 +258,11 @@ Spring Cloud Contract Verifier will create test class `defaultBasePackage.MyServ
 - `shouldCreateUser()`
 - `shouldReturnUser()`

-==== Run plugin
+===== Run plugin

 Plugin goal `generateTests` is assigned to be invoked in phase `generate-test-sources`. You have nothing to do as long as you want it to be part of your build process. If you just want to generate tests please invoke `generateTests` goal.

-==== Configure plugin
+===== Configure plugin

 To change default configuration just add `configuration` section to plugin definition or `execution` definition.

@@ -287,7 +287,7 @@ To change default configuration just add `configuration` section to plugin defin
 </plugin>
 ----

-===== Important configuration options
+====== Important configuration options

 - **testMode** - defines mode for acceptance tests. By default `MockMvc` which is based on Spring's MockMvc. It can also be changed to `JaxRsClient` or to `Explicit` for real HTTP calls.
 - **basePackageForTests** - specifies base package for all generated tests. By default set to `org.springframework.cloud.verifier.tests`.
@@ -298,7 +298,7 @@ To change default configuration just add `configuration` section to plugin defin

 For complete information take a look at https://cloud.spring.io/spring-cloud-contract/spring-cloud-contract-maven-plugin/plugin-info.html[Plugin Documentation]

-===== Base class for tests
+====== Base class for tests

 When using Spring Cloud Contract Verifier in default MockMvc you need to create a base specification for all generated acceptance tests. In this class you need to point to endpoint which should be verified.

@@ -319,7 +319,7 @@ class  MvcSpec extends Specification {

 In case of using `Explicit` mode, you can use base class to initialize the whole tested app similarly as in regular integration tests. In case of `JAXRSCLIENT` mode this base class should also contain `protected WebTarget webTarget` field, right now the only option to test JAX-RS API is to start a web server.

-==== Invoking generated tests
+===== Invoking generated tests

 Spring Cloud Contract Verifier Maven Plugins generates verification code into directory `/generated-test-sources/contractVerifier` and attach this directory to `testCompile` goal.

@@ -359,7 +359,7 @@ For Groovy Spock code use:

 To ensure that provider side is complaint with defined contracts, you need to invoke `mvn generateTest test`

-==== Spring Cloud Contract Verifier on consumer side
+===== Spring Cloud Contract Verifier on consumer side

 In consumer service you need to configure Spring Cloud Contract Verifier plugin in exactly the same way as in case of provider. You need to copy contracts stored in `src/test/resources/contracts` and generate Wiremock json stubs using: `mvn generateStubs` command. By default generated WireMock mapping is stored in directory `target/mappings`. Your project should create from this generated mappings additional artifact with classifier `stubs` for easy deploy to maven repository.

@@ -411,7 +411,7 @@ class LoanApplicationServiceSpec extends Specification {

 Underneath LoanApplication makes a call to FraudDetection service. This request is handled by Wiremock server configured using stubs generated by Spring Cloud Contract Verifier.

-=== Scenarios
+==== Scenarios

 It's possible to handle scenarios with Spring Cloud Contract Verifier. All you need to do is to stick to proper naming convention while creating your contracts. The convention requires to include order number followed by the underscore.

--- a/docs/src/main/asciidoc/verifier/stubrunner.adoc
+++ b/docs/src/main/asciidoc/verifier/stubrunner.adoc
@@ -1,11 +1,11 @@
-== Spring Cloud Contract Stub Runner
+=== Spring Cloud Contract Stub Runner

 One of the issues that you could have encountered while using Spring Cloud Contract Verifier was to pass the generated WireMock JSON stubs from the server side to the client side (or various clients).
 The same takes place in terms of client side generation for messaging.

 Copying the JSON files / setting the client side for messaging manually is out of the question.

-=== Snapshot versions
+==== Snapshot versions

 Add the additional snapshot repository to your build.gradle to use snapshot versions which are automatically uploaded after every successful build:

@@ -18,11 +18,11 @@ repositories {
 }
 ----

-=== Publishing stubs as JARs
+==== Publishing stubs as JARs

 The easiest approach would be to centralize the way stubs are kept. For example you can keep them as JARs in a Maven repository.

-==== Gradle
+===== Gradle

 Example of Spring Cloud Contract Verifier Gradle setup:

@@ -31,11 +31,11 @@ Example of Spring Cloud Contract Verifier Gradle setup:
 include::{plugins_path}/spring-cloud-contract-gradle-plugin/src/test/resources/functionalTest/scenarioProject/build.gradle[tags=jar_setup,indent=0]
 ----

-==== Maven
+===== Maven

 Example of Maven can be found in the https://github.com/spring-cloud/spring-cloud-contract/[Spring Cloud Contract Verifier README]

-=== Modules
+==== Modules

 Spring Cloud Contract Stub Runner comes with a new structure of modules

@@ -62,7 +62,7 @@ include::{stubrunner_core_path}/spring-cloud-contract-stub-runner-spring/README.
 include::{stubrunner_core_path}/spring-cloud-contract-stub-runner-spring-cloud/README.adoc[]


-=== Common properties for JUnit and Spring
+==== Common properties for JUnit and Spring

 Some of the properties that are repetitive can be set using system properties or property sources (for Spring). Here are their names with their default values:

@@ -77,7 +77,7 @@ Some of the properties that are repetitive can be set using system properties or
 |stubrunner.stubs.ids|| Comma separated list of Ivy notation of stubs to download
 |======================

-==== Stub runner stubs ids
+===== Stub runner stubs ids

 You can provide the stubs to download via the `stubrunner.stubs.ids` system property. They follow the following pattern:

--- a/docs/src/main/asciidoc/verifier/stubrunner_msg.adoc
+++ b/docs/src/main/asciidoc/verifier/stubrunner_msg.adoc
@@ -1,4 +1,4 @@
-== Stub Runner for Messaging
+=== Stub Runner for Messaging

 Stub Runner has the functionality to run the published stubs in memory. It can integrate with the following frameworks out of the box

@@ -8,7 +8,7 @@ Stub Runner has the functionality to run the published stubs in memory. It can i

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

-=== Stub triggering
+==== Stub triggering

 To trigger a message it's enough to use the `StubTrigger` interface:

@@ -21,21 +21,21 @@ For convenience the `StubFinder` interface extends `StubTrigger` so it's enough

 `StubTrigger` gives you the following options to trigger a message:

-==== Trigger by label
+===== Trigger by label

 [source,groovy]
 ----
 include::{stubrunner_core_path}/spring-cloud-contract-stub-runner-messaging/spring-cloud-contract-stub-runner-camel/src/test/groovy/org/springframework/cloud/contract/stubrunner/messaging/camel/CamelStubRunnerSpec.groovy[tags=client_trigger,indent=0]
 ----

-===== Trigger by group and artifact ids
+====== Trigger by group and artifact ids

 [source,groovy]
 ----
 include::{stubrunner_core_path}/spring-cloud-contract-stub-runner-messaging/spring-cloud-contract-stub-runner-camel/src/test/groovy/org/springframework/cloud/contract/stubrunner/messaging/camel/CamelStubRunnerSpec.groovy[tags=trigger_group_artifact,indent=0]
 ----

-===== Trigger by artifact ids
+====== Trigger by artifact ids

 [source,groovy]
 ----