spring-cloud-contract | Support for Consumer Driven Contracts in Spring | Microservice library

I would like to know how am I supposed to create in Groovy the Json payload with a random value. For example

I'm learning about Spring Cloud Contract and have a question regarding the supported languages. While writing SCC Stub runner based contract tests the documentation seems to imply that we're supporting tests written in either JUnit or Spock.

https://cloud.spring.io/spring-cloud-contract/1.2.x/multi/multi__spring_cloud_contract_stub_runner.html

Can we use the Spring Cloud Contract Stub Runner only for Java / Groovy languages or does it support other languages as well?

I am trying to introduce path param in urlPath as regexp in the following way:

My team is creating 2 microservices. One in Spring - consumer and another in Node.js - producer. They will communicate through http rest api.

We would like to test them using contract. I've seen https://spring.io/blog/2018/02/13/spring-cloud-contract-in-a-polyglot-world but it's a different case (producer is on Java side and consumer is on Js).

Is there a way to define contract and generate tests for both microservices in such case?

Currently we have a github repo where we store all the contracts, another repo which contains the producer code, and last but not least another one which contains the consumer code.

On the consumer side working with branches when pointing to the contract repo is well supported by using properties like stubrunner.properties.git.branch (more info can be found here https://cloud.spring.io/spring-cloud-contract/reference/html/appendix.html#additional-application-properties)

But on the producer I can not see any way of using the contracts of a concrete branch, we just can point to the github repo where contracts are stored by using contractsRepositoryUrl of the spring-cloud-contract-maven-plugin

This will be very useful to create a flow of contract testing :

• a PR to contract testing repo with the proposal
• which will trigger the producer job (passing the pr branch name)
• if the repo with the contracts contains the bindings, populated by the producer(previous step), then we could trigger the consumer job and validate if everything is fine with these proposed changes
• once the 2 builds are green (producer and consumer) we can merge the changes on the contracts repo

UPDATE : the following spring-cloud-contract-maven-plugin config worked for me, also you can set this property through command line like this -Dstubrunner.properties.git.branch=other_branch_than_master

My question addresses a conceptual issue with consumer driven contracts (CDCs), not with Spring-Cloud-Contract in particular (though tagged otherwise).

A CDC usually guarantees a particular behavior of a service (producer/supplier) to its client (consumer). Many architectures (e.g. Hexagonal/Clean/Onion Architecture) have an adapter/layer to provide the technical interface(s) of the service (REST/SOAP/Messaging/...). They separate the adapter from the business logic. When tests are written based on a CDC it is possible to just test the adapter (classical unit test) and mock away the business logic.

However, the contract formally does not only specify a particular mapping of the result (from the business logic) to the data transfer object as returned by the adapter. Moreover it contains semantics wrt. to the request/response behavior: If the consumer sends a specific request with meaningful data, the producer should respond with a particular correct answer (with respect to the request).

My point for discussion/question is: Should the test on the producer side then be an integration test (integrating business logic) to check if the business logic will return the correct answer? In this case the next layer (behind business logic) might be mocked away as long as the business logic is an integral part of the test case.

In Spring CDCs (but I think in other CDC implementations as well) it is possible to distinguish between consumer and producer side and the generated test cases. For example it would be possible to reduce the producer part to check for formal correctness of the response (e.g., if a particular data item is contained and validates against a pattern) while it specifies a concrete response for the consumer part at the same time. This might lead to the (mis-) understanding on the consumer side (and backed by the consumer tests) that the concrete specified data would be returned by the producer if the consumer had sent the specified request from the CDC.

What do users of CDCs think? How do you specify behavior and to what extent do you test it on the producer side?

The idea is to have one file for both - contract definition and contract test specification.

I found the plugin 'guru.springframework:spring-cloud-contract-oa3:2.1.2.0' which should make what I want but it fails for me. I based my config on the examples from this repo https://github.com/springframeworkguru/sccoa3-fraud-example

Here is the error message after executing

gradle build clean

When writing a contract for an API i found myself repeating the same things over and over. For example regex validations for complex json object need to be copy pasted. Thats tedious and not very DRY.

I'm using Kotlin DSL and Maven

I tried to extract the common parts in another file to reuse it. (Kotlin extension functions ftw.)

After trying multiple things to reuse that file I gave up.

The common parts should be as close to the actual contracts as possible. I don't want to export them in another project, and build them seperat, as they are an vital part of the contracts.

I tried it the following ways:

1. just put the file in the same directory and importing the functions, hoping it would be resolved as it would in java - did not work at all (my expectations were low, was worth a shot)
2. putting it in another maven module, and add that as dependency to the spring-cloud-contract-maven-plugin. that worked, as long as the dependant module was built and installed in the local maven repo. if no built version was available maven could not resolve it.
3. experimenting with kotlin script @file:Import() and @file:DependOn to tackle my issue, no luck.

Is there another way, that I missed? Is there a prefered way doing this? This must be a common issue, right?

Design Overview

• Request and response objects are modelled in protobuf.
• Classes are generated in Python and Java using protoc.
• Users create request objects in Python and send it to RESTful Java Spring Boot microservices.
• A JavaScript React web application and Node server also invoke the RESTful endpoints.
• Requests and responses are serialized to Json.
• 1+ Java microservices may use the same request/response objects. eg. an aggregator/API gateway microservice will pass on the request to the actual microservice, providing the relevant service.

Question

Protobuf enforces some level of type checking, and a kind of contract, for request/response objects. However, how do I develop, maintain and enforce RESTful contracts (HTTP verb + path + request + response)?

Is this the way to go?

Develop contracts in Spring Cloud Contract and auto-generate integration contract tests.