[[how-to-provide-dynamic-values]]
= How Can I Provide Dynamic Values to a Contract?

include::partial$_attributes.adoc[]

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:

[source,json,indent=0]
----
{
    "time" : "2016-10-10 20:10:15",
    "id" : "9febab1c-6f36-4a0b-88d6-3b6a6d81cd4a",
    "body" : "foo"
}
----

Now consider the following JSON response:

[source,json,indent=0]
----
{
    "time" : "2016-10-10 21:10:15",
    "id" : "c4231e1f-3ca9-48d3-b7e7-567d55f0d051",
    "body" : "bar"
}
----

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.

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:

[source,json,indent=0]
----
{
    "time" : "SOMETHING THAT MATCHES TIME",
    "id" : "SOMETHING THAT MATCHES UUID",
    "body" : "foo"
}
----

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:

[source,json,indent=0]
----
{
    "time" : "2016-10-10 21:10:15",
    "id" : "c4231e1f-3ca9-48d3-b7e7-567d55f0d051",
    "body" : "bar"
}
----

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:

[source,json,indent=0]
----
{
    "time" : "2016-10-10 20:10:15",
    "id" : "9febab1c-6f36-4a0b-88d6-3b6a6d81cd4a",
    "body" : "foo"
}
----

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:

[source,json,indent=0]
----
{
    "time" : "SOMETHING THAT MATCHES TIME",
    "id" : "SOMETHING THAT MATCHES UUID",
    "body" : "bar"
}
----

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.

You can read more about this in the xref:project-features-contract.adoc[Contract DSL] section.

IMPORTANT: Read the https://groovy-lang.org/json.html[Groovy docs related to JSON] to understand how to
properly structure the request and response bodies.

