Hello everyone. Can someone please help me to sort out two questions: 1. Am I right that in consumer tests, in VerifyAsync method we call MockServer to confirm that the request was executed, and at the same time we have to return a stub result to execute assert section? The way I see it, we generate a pact file and run a unit-test, is that the point? 2. What are the dangers of just calling the HttpClient Get method in VerifyAsync and then closing assertion by calling Assert.True(true) in Consumer tests?

1. Yes. Except it’s not a stub, it’s a mock (a mock checks behaviour, a stub does not). So you mock the API provider, run a unit test of your API client, which must call the API provider. The mock itself performs part of those assertions, and is used later on to check if the provider behaves correctly also 2. Maybe it’s a .NET thing, but why would you ever run that assertion (i.e. do you have to have at least one assertion to make the framework happy)? Can you just omit it altogether? There may be other assertions on the behaviour of the API client you need to run, but if not, I think what you’re asking is fine

Thanks Matt, that makes more sense to me now. About assertion - I'm referring to the example from the documentation, that's why I had a question, what's the point of these assertions, if in fact the expected result is set in pactBuilder.WillRespond() method.

The expected result is not that the API returned the data you told it would, it’s that the API client behaved the way you thought it would. e.g. it might take the HTTP response, unmarshal into a domain model etc. That might be worth testing. If your API client is very basic, then maybe you don’t need additional assertions. But the idea is to unit test the API client - so you’re on the right path if that’s your mindset