ITV / scala-pact

A Scala implementation of CDC using the Pact standard
Other
108 stars 54 forks source link

add ability to forge pacts without running consumer tests #193

Closed jbwheatley closed 3 years ago

davesmith00000 commented 3 years ago

You're merging PR's faster than I can get to them, so apologies for the delayed comment. Why would we want this? What's the use case? The point of pact testing it to ensure Pact's aren't written without having been tested.

jbwheatley commented 3 years ago

@davesmith00000 hey, sorry I need to write up a ticket that make my intentions a bit more clear. I'm working on the test suite and want users to be able to define pacts and write their tests separately, with a global stubber for the entire suite. So at the top you declare all your pacts that get written to the stubber, and then below you'd have all of your tests against the stubber.

davesmith00000 commented 3 years ago

Are you saying something like:

  1. Define all Pacts
  2. Run global stub
  3. Run all pact tests against the stub
  4. Publish all if successful

Is that it?

If so the only snag would be where you want the stubber to say something different against the same request. Which is not great practice to be fair because it messes up verification, but it's also legal and we have no way to force you not to reuse endpoints currently.

jbwheatley commented 3 years ago

Yeah, that was the general idea. My main motivation was that starting a http4s server per test is fairly heavy operation.

Hmm, good point.. but I think this would force you to not reuse requests for different pacts, because the global stubber would return the same response in both cases (so one test would presumably always fail)? So, for example, if you wanted to forge 2 pacts with identical request but against different provider states you couldn't do it in the same suite. Maybe this is infeasible then, as it doesn't seem like that too farfetched of a use-case.

davesmith00000 commented 3 years ago

Actually there might be an advantages to this, since the pacts can be considered together rather than being totally independent, we can do validation across all the pacts as a group, i.e. we could error if we saw two identical request definitions that expected different responses (all the equality machinery already exists).