This version is still in development and is not considered stable yet. For the latest stable version, please use spring-cloud-contract 4.3.0!

WireMock Customization

In this section, we show how to customize the way you work with WireMock.

Registering Your Own WireMock Extension

WireMock lets you register custom extensions. By default, Spring Cloud Contract registers the transformer, which lets you reference a request from a response. If you want to provide your own extensions, you can register an implementation of the org.springframework.cloud.contract.verifier.dsl.wiremock.WireMockExtensions interface. Since we use the spring.factories extension approach, you can create an entry similar to the following in the META-INF/spring.factories file:

org.springframework.cloud.contract.verifier.dsl.wiremock.WireMockExtensions=\
org.springframework.cloud.contract.stubrunner.provider.wiremock.TestWireMockExtensions
org.springframework.cloud.contract.spec.ContractConverter=\
org.springframework.cloud.contract.stubrunner.TestCustomYamlContractConverter

The following example shows a custom extension:

TestWireMockExtensions.groovy

import com.github.tomakehurst.wiremock.extension.Extension

/**
 * Extension that registers the default transformer and the custom one
 */
class TestWireMockExtensions implements WireMockExtensions {
	@Override
	List<Extension> extensions() {
		return [
				new DefaultResponseTransformer(),
				new CustomExtension()
		]
	}
}

class CustomExtension implements Extension {

	@Override
	String getName() {
		return "foo-transformer"
	}
}

If you want the transformation to be applied only for a mapping that explicitly requires it, override the applyGlobally() method and set it to false .

Customization of WireMock via Metadata

With version 3.0.0 you’re able to set metadata in your contracts. If you set an entry with key equal to wiremock and the value will be a valid WireMock’s StubMapping JSON / map or an actual StubMapping object, Spring Cloud Contract will patch the generated stub with part of your customization. Let’s look at the following example

Click here to see the code

In the metadata section we’ve set an entry with key wiremock and its value is a JSON StubMapping that sets a delay in the generated stub. Such code allowed us to get the following merged WireMock JSON stub.

{
  "id" : "ebae49e2-a2a3-490c-a57f-ba28e26b81ea",
  "request" : {
    "url" : "/yamlfrauds",
    "method" : "GET"
  },
  "response" : {
    "status" : 200,
    "body" : "{\"count\":200}",
    "headers" : {
      "Content-Type" : "application/json"
    },
    "fixedDelayMilliseconds" : 2000,
    "transformers" : [ "response-template" ]
  },
  "uuid" : "ebae49e2-a2a3-490c-a57f-ba28e26b81ea"
}

The current implementation allows to manipulate only the stub side (we don’t change the generated test). Also, what does not get changed are the whole request and body and headers of the response.

Customization of WireMock via Metadata and a Custom Processor

If you want to apply a custom WireMock StubMapping post processing, you can under META-INF/spring.factories under the org.springframework.cloud.contract.verifier.converter.StubProcessor key register your own implementation of a stub processor. For your convenience we’ve created an interface called org.springframework.cloud.contract.verifier.wiremock.WireMockStubPostProcessor that is dedicated to WireMock.

You’ll have to implement methods to inform Spring Cloud Contract whether the post processor is applicable for a given contract and how should the post processing look like.

On the consumer side, when using Stub Runner, remember to pass the custom HttpServerStubConfigurer implementation (e.g. the one that extends WireMockHttpServerStubConfigurer) where you’ll register a custom extension of your choosing. If you don’t do so, even you have a custom WireMock extension on the classpath, WireMock will not notice it, won’t apply it and will print out a warning statement that the given extension was not found.