You may encounter cases where your contracts have been defined in other formats, such as YAML, RAML, or PACT. In those cases, you still want to benefit from the automatic generation of tests and stubs. You can add your own implementation for generating both tests and stubs. Also, you can customize the way tests are generated (for example, you can generate tests for other languages) and the way stubs are generated (for example, you can generate stubs for other HTTP server implementations).
The ContractConverter
interface lets you register your own implementation of a contract
structure converter. The following code listing shows the ContractConverter
interface:
link:{contract_spec_path}/src/main/java/org/springframework/cloud/contract/spec/ContractConverter.java[role=include]
Your implementation must define the condition on which it should start the conversion. Also, you must define how to perform that conversion in both directions.
Important
|
Once you create your implementation, you must create a
/META-INF/spring.factories file in which you provide the fully qualified name of your
implementation.
|
The following example shows a typical spring.factories
file:
org.springframework.cloud.contract.spec.ContractConverter=\
org.springframework.cloud.contract.verifier.converter.YamlContractConverter
If you want to generate tests for languages other than Java or you are not happy with the way the verifier builds Java tests, you can register your own implementation.
The SingleTestGenerator
interface lets you register your own implementation. The
following code listing shows the SingleTestGenerator
interface:
link:{verifier_root_path}/src/main/java/org/springframework/cloud/contract/verifier/builder/SingleTestGenerator.java[role=include]
Again, you must provide a spring.factories
file, such as the one shown in the following
example:
org.springframework.cloud.contract.verifier.builder.SingleTestGenerator=/
com.example.MyGenerator
If you want to generate stubs for stub servers other than WireMock, you can plug in your
own implementation of the StubGenerator
interface. The following code listing shows the
StubGenerator
interface:
link:{converters_path}/src/main/java/org/springframework/cloud/contract/verifier/converter/StubGenerator.java[role=include]
Again, you must provide a spring.factories
file, such as the one shown in the following
example:
link:{converters_path}/src/main/resources/META-INF/spring.factories[role=include]
The default implementation is the WireMock stub generation.
Tip
|
You can provide multiple stub generator implementations. For example, from a single DSL, you can produce both WireMock stubs and Pact files. |
If you decide to use custom stub generation, you also need a custom way of running stubs with your different stub provider.
Assume that you use Moco to build your stubs and that you have written a stub generator and placed your stubs in a JAR file.
In order for Stub Runner to know how to run your stubs, you have to define a custom HTTP Stub server implementation, which might resemble the following example:
link:{tests_path}/spring-cloud-contract-stub-runner-moco/src/test/groovy/org/springframework/cloud/contract/stubrunner/provider/moco/MocoHttpServerStub.groovy[role=include]
Then you can register it in your spring.factories
file, as the following
example shows:
org.springframework.cloud.contract.stubrunner.HttpServerStub=\
org.springframework.cloud.contract.stubrunner.provider.moco.MocoHttpServerStub
Now you can run stubs with Moco.
Important
|
If you do not provide any implementation, the default (WireMock) implementation is used. If you provide more than one, the first one on the list is used. |
You can customize the way your stubs are downloaded by creating an implementation of the
StubDownloaderBuilder
interface, as the following example shows:
package com.example;
class CustomStubDownloaderBuilder implements StubDownloaderBuilder {
@Override
public StubDownloader build(final StubRunnerOptions stubRunnerOptions) {
return new StubDownloader() {
@Override
public Map.Entry<StubConfiguration, File> downloadAndUnpackStubJar(
StubConfiguration config) {
File unpackedStubs = retrieveStubs();
return new AbstractMap.SimpleEntry<>(
new StubConfiguration(config.getGroupId(), config.getArtifactId(), version,
config.getClassifier()), unpackedStubs);
}
File retrieveStubs() {
// here goes your custom logic to provide a folder where all the stubs reside
}
}
}
}
Then you can register it in your spring.factories
file, as the following
example shows:
# Example of a custom Stub Downloader Provider
org.springframework.cloud.contract.stubrunner.StubDownloaderBuilder=\
com.example.CustomStubDownloaderBuilder
Now you can pick a folder with the source of your stubs.
Important
|
If you do not provide any implementation, the default (scanning the classpath) is used.
If you provide the stubsMode = StubRunnerProperties.StubsMode.LOCAL or
stubsMode = StubRunnerProperties.StubsMode.REMOTE , the Aether implementation is used
If you provide more than one, the first one on the list is used.
|
Whenever the repositoryRoot
starts with a SCM protocol
(currently, we support only git://
), the stub downloader tries
to clone the repository and use it as a source of contracts
to generate tests or stubs.
Through environment variables, system properties, or properties set inside the plugin or the contracts repository configuration, you can tweak the downloader’s behavior. The following table describes the available properties:
Type of a property |
Name of the property |
Description |
* * * |
master |
Which branch to checkout |
* * * |
Git clone username |
|
* * * |
Git clone password |
|
* * * |
10 |
Number of attempts to push the commits to |
* * * |
1000 |
Number of milliseconds to wait between attempts to push the commits to |