The following example shows how to set up a base class and Rest Assured for Web Flux:
Unresolved directive in verifier_contract.adoc - include::https://raw.githubusercontent.com/spring-cloud-samples/spring-cloud-contract-samples/master/producer_webflux/src/test/java/com/example/BeerRestBase.java[tags=annotations,indent=0] // your tests go here // in this config class you define all controllers and mocked services -@Configuration -@EnableAutoConfiguration -static class Config { - - @Bean - PersonCheckingService personCheckingService() { - return personToCheck -> personToCheck.age >= 20; - } - - @Bean - ProducerController producerController() { - return new ProducerController(personCheckingService()); - } -} +Unresolved directive in verifier_contract.adoc - include::https://raw.githubusercontent.com/spring-cloud-samples/spring-cloud-contract-samples/master/producer_webflux/src/test/java/com/example/BeerRestBase.java[tags=config,indent=0] }
The DSL for messaging looks a little bit different than the one that focuses on HTTP. The following sections explain the differences:
The output message can be triggered by calling a method (such as a Scheduler when a was
diff --git a/multi/multi__customization.html b/multi/multi__customization.html
index 3522c8d4ec..d2133c646e 100644
--- a/multi/multi__customization.html
+++ b/multi/multi__customization.html
@@ -3,215 +3,16 @@
![[Important]](images/important.png) | Important |
|---|---|
This section is valid only for Groovy DSL |
You can customize the Spring Cloud Contract Verifier by extending the DSL, as shown in the remainder of this section.
You can provide your own functions to the DSL. The key requirement for this feature is to maintain the static compatibility. Later in this document, you can see examples of:
- Creating a JAR with reusable classes.
- Referencing of these classes in the DSLs.
You can find the full example -here.
The following examples show three classes that can be reused in the DSLs.
PatternUtils contains functions used by both the consumer and the producer.
package com.example; - -import java.util.regex.Pattern; - -/** - * If you want to use {@link Pattern} directly in your tests - * then you can create a class resembling this one. It can - * contain all the {@link Pattern} you want to use in the DSL. - * - * <pre> - * {@code - * request { - * body( - * [ age: $(c(PatternUtils.oldEnough()))] - * ) - * } - * </pre> - * - * Notice that we're using both {@code $()} for dynamic values - * and {@code c()} for the consumer side. - * - * @author Marcin Grzejszczak - */ -//tag::impl[] -public class PatternUtils { - - public static String tooYoung() { - //remove::start[] - return "[0-1][0-9]"; - //remove::end[return] - } - - public static Pattern oldEnough() { - //remove::start[] - return Pattern.compile("[2-9][0-9]"); - //remove::end[return] - } - - /** - * Makes little sense but it's just an example ;) - */ - public static Pattern ok() { - //remove::start[] - return Pattern.compile("OK"); - //remove::end[return] - } -} -//end::impl[]
ConsumerUtils contains functions used by the consumer.
package com.example; - -import org.springframework.cloud.contract.spec.internal.ClientDslProperty; - -/** - * DSL Properties passed to the DSL from the consumer's perspective. - * That means that on the input side {@code Request} for HTTP - * or {@code Input} for messaging you can have a regular expression. - * On the {@code Response} for HTTP or {@code Output} for messaging - * you have to have a concrete value. - * - * @author Marcin Grzejszczak - */ -//tag::impl[] -public class ConsumerUtils { - /** - * Consumer side property. By using the {@link ClientDslProperty} - * you can omit most of boilerplate code from the perspective - * of dynamic values. Example - * - * <pre> - * {@code - * request { - * body( - * [ age: $(ConsumerUtils.oldEnough())] - * ) - * } - * </pre> - * - * That way it's in the implementation that we decide what value we will pass to the consumer - * and which one to the producer. - * - * @author Marcin Grzejszczak - */ - public static ClientDslProperty oldEnough() { - //remove::start[] - // this example is not the best one and - // theoretically you could just pass the regex instead of `ServerDslProperty` but - // it's just to show some new tricks :) - return new ClientDslProperty(PatternUtils.oldEnough(), 40); - //remove::end[return] - } - -} -//end::impl[]
ProducerUtils contains functions used by the producer.
package com.example; - -import org.springframework.cloud.contract.spec.internal.ServerDslProperty; - -/** - * DSL Properties passed to the DSL from the producer's perspective. - * That means that on the input side {@code Request} for HTTP - * or {@code Input} for messaging you have to have a concrete value. - * On the {@code Response} for HTTP or {@code Output} for messaging - * you can have a regular expression. - * - * @author Marcin Grzejszczak - */ -//tag::impl[] -public class ProducerUtils { - - /** - * Producer side property. By using the {@link ProducerUtils} - * you can omit most of boilerplate code from the perspective - * of dynamic values. Example - * - * <pre> - * {@code - * response { - * body( - * [ status: $(ProducerUtils.ok())] - * ) - * } - * </pre> - * - * That way it's in the implementation that we decide what value we will pass to the consumer - * and which one to the producer. - */ - public static ServerDslProperty ok() { - // this example is not the best one and - // theoretically you could just pass the regex instead of `ServerDslProperty` but - // it's just to show some new tricks :) - return new ServerDslProperty( PatternUtils.ok(), "OK"); - } -} -//end::impl[]
In order for the plugins and IDE to be able to reference the common JAR classes, you need +here.
The following examples show three classes that can be reused in the DSLs.
PatternUtils contains functions used by both the consumer and the producer.
Unresolved directive in verifier_contract.adoc - include::https://raw.githubusercontent.com/spring-cloud-samples/spring-cloud-contract-samples/master/common/src/main/java/com/example/PatternUtils.java[]ConsumerUtils contains functions used by the consumer.
Unresolved directive in verifier_contract.adoc - include::https://raw.githubusercontent.com/spring-cloud-samples/spring-cloud-contract-samples/master/common/src/main/java/com/example/ConsumerUtils.java[]ProducerUtils contains functions used by the producer.
Unresolved directive in verifier_contract.adoc - include::https://raw.githubusercontent.com/spring-cloud-samples/spring-cloud-contract-samples/master/common/src/main/java/com/example/ProducerUtils.java[]In order for the plugins and IDE to be able to reference the common JAR classes, you need to pass the dependency to your project.
First, add the common jar dependency as a test dependency. Because your contracts files are available on the test resources path, the common jar classes automatically become visible in your Groovy files. The following examples show how to test the dependency:
Maven. -
<dependency> - <groupId>com.example</groupId> - <artifactId>beer-common</artifactId> - <version>${project.version}</version> - <scope>test</scope> -</dependency>
+
Unresolved directive in verifier_contract.adoc - include::https://raw.githubusercontent.com/spring-cloud-samples/spring-cloud-contract-samples/master/producer/pom.xml[tags=test_dep,indent=0]
Gradle. -
testCompile("com.example:beer-common:0.0.1-SNAPSHOT")+
Unresolved directive in verifier_contract.adoc - include::https://raw.githubusercontent.com/spring-cloud-samples/spring-cloud-contract-samples/master/producer/build.gradle[tags=test_dep,indent=0]
Now, you must add the dependency for the plugin to reuse at runtime, as shown in the following example:
Maven. -
<plugin> - <groupId>org.springframework.cloud</groupId> - <artifactId>spring-cloud-contract-maven-plugin</artifactId> - <version>${spring-cloud-contract.version}</version> - <extensions>true</extensions> - <configuration> - <packageWithBaseClasses>com.example</packageWithBaseClasses> - <baseClassMappings> - <baseClassMapping> - <contractPackageRegex>.*intoxication.*</contractPackageRegex> - <baseClassFQN>com.example.intoxication.BeerIntoxicationBase</baseClassFQN> - </baseClassMapping> - </baseClassMappings> - </configuration> - <dependencies> - <dependency> - <groupId>com.example</groupId> - <artifactId>beer-common</artifactId> - <version>${project.version}</version> - <scope>compile</scope> - </dependency> - </dependencies> -</plugin>
+
Unresolved directive in verifier_contract.adoc - include::https://raw.githubusercontent.com/spring-cloud-samples/spring-cloud-contract-samples/master/producer/pom.xml[tags=test_dep_in_plugin,indent=0]
Gradle. -
classpath "com.example:beer-common:0.0.1-SNAPSHOT"-
You can now reference your classes in your DSL, as shown in the following example:
package contracts.beer.rest - -import com.example.ConsumerUtils -import com.example.ProducerUtils -import org.springframework.cloud.contract.spec.Contract - -Contract.make { - description(""" -Represents a successful scenario of getting a beer - -``` -given: - client is old enough -when: - he applies for a beer -then: - we'll grant him the beer -``` - -""") - request { - method 'POST' - url '/check' - body( - age: $(ConsumerUtils.oldEnough()) - ) - headers { - contentType(applicationJson()) - } - } - response { - status 200 - body(""" - { - "status": "${value(ProducerUtils.ok())}" - } - """) - headers { - contentType(applicationJson()) - } - } -}