bodyMatchers' validations are not overwriting equality validation in request body

[EdgardHernandezp]

I'm using the body matchers section of the contract to validate the userId field which must be an UUID. The problem arises when I build the project and generate the stub which has a equality validation and a UUID regex validation at the same time. The expected behavior is to have only the UUID regex validation.

This breakes the integration test in the consumer side because the mock server is basically trying to match like:

userId.equals("specificUserID") && isUUID()

and I just need:

isUUID()

You might say: "well the user can simply pass the specific UUID defined in the stub" but that would take freedom and independence to the consumer which goes against the intent of contract testing.

PD: I'm using spring-cloud-starter-contract-verifier version 4.1.0

[marcingrzejszczak]

That's a bug. WHen you're using a jsonpath matcher then it should not do the equality check

[marcingrzejszczak]

Ah, you have a bug in your contract.

rg.springframework.cloud.contract.spec.Contract.
					make {
						request {
							method('PUT')
							url("/fetch-recommendations")
							headers {
								header(contentType(), applicationJson())
							}
							body(
								userId: "e9fbebcf-abb4-4097-831a-f3f279714d8",
								preferedGenres: [
								        "Platformer", "Stealth", "Adventrure"
								]
							)
							bodyMatchers {
								jsonPath('$.userId', byRegex(uuid()))
							}
						}
						response {
							status OK()
						}
					}

You have an extra toString() after byRegex(...)

[EdgardHernandezp]

I removed the "asString()" instruction and is still happening

I believe you didn't replicated it accurately, this is happening when the body is coming from a separated json file. I left pictures of the json file describing the request body and the contract referencing it through file(String).

request.json <-- here's the json representing the request body
when_received_correct_user_preferences_0.json <- this is the generated mapping

@marcingrzejszczak could you please give it another try with the right scenario?

[marcingrzejszczak]

Sure, I'll check it out tomorrow

[EdgardHernandezp]

Hi! Any news for this?