How Can I Provide Dynamic Values to a Contract?

One of the biggest challenges related to stubs is their reusability. Only if they can be widely used can they serve their purpose. The hard-coded values (such as dates and IDs) of request and response elements generally make that difficult. Consider the following JSON request:spring-doc.cn

Now consider the following JSON response:spring-doc.cn

Imagine the pain required to set the proper value of the time field (assume that this content is generated by the database) by changing the clock in the system or by providing stub implementations of data providers. The same is related to the id field. You could create a stubbed implementation of UUID generator, but doing so makes little sense.spring-doc.cn

So, as a consumer, you want to send a request that matches any form of a time or any UUID. That way, your system works as usual, generating data without you having to stub out anything. Assume that, in case of the aforementioned JSON, the most important part is the body field. You can focus on that and provide matching for other fields. In other words, you would like the stub to work as follows:spring-doc.cn

As far as the response goes, as a consumer, you need a concrete value on which you can operate. Consequently, the following JSON is valid:spring-doc.cn

In the previous sections, we generated tests from contracts. So, from the producer’s side, the situation looks much different. We parse the provided contract, and, in the test, we want to send a real request to your endpoints. So, for the case of a producer for the request, we cannot have any sort of matching. We need concrete values on which the producer’s backend can work. Consequently, the following JSON would be valid:spring-doc.cn

On the other hand, from the point of view of the validity of the contract, the response does not necessarily have to contain concrete values for time or id. Suppose you generate those on the producer side. Again, you have to do a lot of stubbing to ensure that you always return the same values. That is why, from the producer’s side, you might want the following response:spring-doc.cn

How can you then provide a matcher for the consumer and a concrete value for the producer (and the opposite at some other time)? Spring Cloud Contract lets you provide a dynamic value. That means that it can differ for both sides of the communication.spring-doc.cn

You can read more about this in the Contract DSL section.spring-doc.cn