anchor.diff:  ----
   
   
  -==== Defining the contract
  +==== Defining the Contract
   
   As consumers of services, we need to define what exactly we want to achieve. We need to
   formulate our expectations. That is why we write contracts.
  
positive.code: }
  ----
  
  The sample above uses Spring's `MockMvc` to run the tests. This is the default test mode for HTTP
  contracts, however also JAX-RX client and explicit HTTP invocations can be used as well (just change
  the `testMode` property of the plugin to `JAX-RS` or `EXPLICIT`.
  
  Apart from the default JUnit, you can also use Spock tests, instead, by setting the plugin `testFramework`
  property to `Spock`.
  
  TIP: 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.
  
  A sample auto-generated test in Spock for a messaging stub contract would look similar to this:
  
   [source,groovy,indent=0]
  ----
  
negative.code: 	 bookWasDeleted()
  ----
  
  As the implementation of the functionalities described by the contracts is not yet
  present, the tests fail.
  
  To make them pass, you must add the correct implementation of handling either HTTP
  requests or messages. Also, you must add a correct base test class for auto-generated
  tests to the project. This class is extended by all the auto-generated tests and should
  contain all the setup necessary to run them (for example, `RestAssuredMockMvc` controller
  setup or messaging test setup).
  
  Once the implementation and the test base class are in place, the tests pass, and both the
  application and the stub artifacts are built and installed in the local Maven repository.
  Information about installing the stubs jar to the local repository appears in the logs, as
  shown in the following example:
  
  [source,bash,indent=0]
  ----
  