Gradle Project

To use Spring Cloud Contract Verifier with WireMock, you must use either a Gradle or a Maven plugin.

To add a Gradle plugin with dependencies, you can use code similar to the following:

By default, Rest Assured 3.x is added to the classpath. However, to use Rest Assured 2.x, you can add it instead, as the following listing shows:

That way, the plugin automatically sees that Rest Assured 2.x is present on the classpath and modifies the imports accordingly.

You can add the additional snapshot repository to your settings.gradle to use snapshot versions, which are automatically uploaded after every successful build.

By default, Spring Cloud Contract Verifier looks for stubs in the src/contractTest/resources/contracts directory. For transitional purposes the plugin will also look for contracts in src/test/resources/contracts, however, this directory is deprecated as of Spring Cloud Contract 3.0.0.

It should also be noted, that with this new Gradle source set, you should also migrate any base classes used within your contract tests to src/contractTest/{language} where {language} should be replaced with Java or Groovy as needed for your purposes.

The directory that contains stub definitions is treated as a class name, and each stub definition is treated as a single test. Spring Cloud Contract Verifier assumes that it contains at least one level of directories that are to be used as the test class name. If more than one level of nested directories is present, all except the last one is used as the package name. Consider the following structure:

Given the preceding structure, Spring Cloud Contract Verifier creates a test class named defaultBasePackage.MyService with two methods:

The plugin registers itself to be invoked before a check task. If you want it to be part of your build process, you need do nothing more. If you want only to generate tests, invoke the generateContractTests task.

The default Gradle Plugin setup creates the following Gradle part of the build (in pseudocode):

To change the default configuration, you can add a contracts snippet to your Gradle configuration, as the following listing shows:

To download contracts from a remote source, you can use the following snippets as needed:

Since we are using Gradle’s Jar packaging task, there are several options and capabilities that you may wish to utilize to further extend what is created by the verifierStubsJar. In order to do this, you would use the native mechanisms provided directly by Gradle for customizing an existing task like so:

It should also be noted that as of 3.0.0, the default publication has been disabled. As a result this means, that you are able to create any named jar and publish it as you would normally have done via Gradle configuration options. This means that you can build a jar file customized just the way you would like and publish that for absolute full control over the jar’s layout and contents.

You can use the following properties when you want to specify the location of the JAR that contains the contracts:

There is also the contractRepository { …​ } closure that contains the following properties

You can also turn on the following experimental features in the plugin:

When using Spring Cloud Contract Verifier in MockMvc (the default), you need to create a base specification for all generated acceptance tests. In this class, you need to point to an endpoint, which should be verified. The following example shows how to do so:

If you use Explicit mode, you can use a base class to initialize the whole tested application, as you might see in regular integration tests. If you use the JAXRSCLIENT mode, this base class should also contain a protected WebTarget webTarget field. Right now, the only option to test the JAX-RS API is to start a web server.

If your base classes differ between contracts, you can tell the Spring Cloud Contract plugin which class should get extended by the autogenerated tests. You have two options:

To ensure that the provider side is compliant with your defined contracts, you need to run the following command:

If you use an binary artifact repository to keep the stubs, you will need to configure the publishing section for Gradle to include the verifierStubsJar. To do that, you can use the example configuration below:

Since 3.0.0, the internal stubs publication has been deprecated and disabled by default. It is recommended to include the verifierStubsJar with one of your own publications.

If you use the SCM repository to keep the contracts and stubs, you might want to automate the step of pushing stubs to the repository. To do that, you can call the pushStubsToScm task by running the following command:

Under Using the SCM Stub Downloader, you can find all possible configuration options that you can pass either through the contractsProperties field (for example, contracts { contractsProperties = [foo:"bar"] }), through the contractsProperties method (for example, contracts { contractsProperties([foo:"bar"]) }), or through a system property or an environment variable.

In a consuming service, you need to configure the Spring Cloud Contract Verifier plugin in exactly the same way as in the case of a provider. If you do not want to use Stub Runner, you need to copy the contracts stored in src/contractTest/resources/contracts and generate WireMock JSON stubs by using the following command:

When present, you can use JSON stubs in automated tests to consume a service. The following example shows how to do so:

In the preceding example, LoanApplication makes a call to the FraudDetection service. This request is handled by a WireMock server configured with stubs that were generated by Spring Cloud Contract Verifier.