(Starting a new thread since this is a somewhat different topic) - I have a messaging use case where a service consumes a message and emits one or more messages in response, which are in turn consumer by other services. I can use pact to assert that the consumed message is as expected, but I'd also like to assert that the emitted messages are as expected, based on the consumed message, similar to how pact works with Http request/response tests. Here's a diagram to illustrate what I mean. The labels on the left indicate how each service emits messages that are derived from the message it consumes. But really, this is similar to a request/response flow, which the labels on the right illustrate. I'd like to be able to verify this type of situation by asserting the incoming messages (requests) and the emitted messages (responses) for each service. Any thoughts on this? Is there a way to accomplish this?

Pact doesn't do this, but I think it should. You might be able to put something together that does it by wrapping the message pact interfaces, but it would be custom. I'm working on an alternative framework that will support this (and ideally be pact-compatible), but it's not ready for use yet.

Interesting, can you ping me when there's something to share? Either here or jonathan@elastic.co.

It depends. There's an analogy to DB requests, like an http request to get a resource might. result in a request to a DB. You'd have a contract where you say: http request -> http response and you could have another contract where you say DB request -> DB response (for example - we don't actually have DB contract tests). You wouldn't want: http request -> DB request

Yea that's a good point, though I did read in the guidelines that the DB example gets into the realm of functional testing, where shouldn't care about whether a DB is involved. That makes sense to me.

I think the general case that you're hitting here is: some request -> some response But sometimes that's asynchronous

Yea, it's asynchronous, and the "response" flows down to another service rather than back to the originator of the first message (which makes it more of a reaction than a response).

So, the contract of "can my http client talk to the http server" doesn't include "did the http server make the right DB call"

The catch is that we don't want Service A to know anything about what Service B might emit. But we do want to assert that Service B emits something appropriate when it consumes a message from Service A.

But we do want to assert that Service B emits something appropriate when it consumes a message from Service A.

Right! I wouldn't do this with the contract test from service A, unless it's part of the communication with service A

...we just wouldn't be able to contract test anything across more than 2 services at a time.

like, it's probably an expectation of service A (eg, hey service B, please save this in your storage)

Yea that makes sense.

So a unit test would assert that an input results in some outputs as expected, and contract tests would assert that those outputs are compatible with the next service(s) down the line.

Yes. You could equivalently say that a contract test asserts that an input (the call to the client code & the actual request on the wire) produces the expected output (returned business object from unmarshalling the actual response on the wire). That is, a contract test is a unit test that crosses service boundaries.