Hello, I want to confirm something regarding matching best practices. If I'm testing an endpoint that gets me the user by it's id, I shouldn't match the id of the returned user exactly, eventhough in reality it should be the same as the one I requested the user for, right?

It depends I guess. If you pass in that ID as a parameter in the provider state and make sure that the user with that ID exists in the provider setup, I don’t see why not. I see myself doing the same pretty frequently. The upside is that you’ll catch the (admittedly highly unlikely) issue that a GET yields a different user, with pretty much no downside to it. On the other hand, this is probably (hopefully!) a case that the provider themselves covered, too..

Yeah, the upside is what I was thinking as well. However having concrete values in the contract feels somewhat odd. I was also considering whether this might impact the broker's ability to detect an existing interaction across contract versions or different consumers. However the only case I can think of is if the concrete value is different, in which case you actually would want to run the verification again.

Yeah, that makes sense. I don’t think I’d recommend generating a new ID for every test run / contract version, either. If you do that, then what’s the advantage over just checking on the type or the format of the ID in the response… I think we’re on the same page here, but I’d love to hear other people’s opinions on this.

It also depends on the goal of the test. If your test goal is to know when you request that endpoint you get a response with an ID included, you're basically testing your response schema. But you could also test: • Response ID == Request ID • Response ID : number • Response ID -> exists in DB There's a principle in Testing which explains that your tests should be deterministic. Fancy word to say your test should always return the same result if you input the same thing. In the case 2 and 3, you would not check that your API is giving you a "wrong" ID. I would personally have two type of tests: one generic which would test the schema, and value type, another one which test the exact response value matches what I requested, the latter could be seen more as a functional security test (you don't want a user to get data which belongs to another user...) Hope it helps.