Pact works in a very interesting way, as summarized in Figure 7-11. The consumer starts by defining the expectations of the producer using a Ruby DSL. Then, you launch a local mock server, and run this expectation against it to create the Pact specification file. The Pact file is just a formal JSON specification; you could obviously handcode these, but using the language API is much easier. This also gives you a running mock server that can be used for further isolated tests of the consumer.
Check it out; see if still actively maintained.
Also: does this require fragile coupling of data in test envy with test expectations? Or maybe you define stateful scenario that starts with blank slate?
Not quite clear on role of mock server when defining expectations. Is this the same mock that client dec team is using to isolate dec/testing from actual downstream service? That's a smart pattern really. It at least ensures that the mock and the real thing agree with one another (even if they both deviate from published apis).
