Draft of non-jvm message pact

1.md

Consumer

1. User declares contract between consumer and provider. Pact builder object is created.

builder {
      serviceConsumer 'MessageConsumer'
      hasPactWith 'MessageProvider'
    }

1. Using builder object, user sets up expectation of message using Pact DSL (message class is a Pact library object)

given:
    builder {
      given 'the provider has data for a message'
      expectsToReceive 'a confirmation message for a group order'
      withMetaData(contentType: 'application/json')
      withContent {
        name 'Bob'
        date = '2000-01-01'
        status 'bad'
        age 100
      }

2. User executes tests showing that the consumer can handle the message correctly

builder.run { Message message ->
      def content = new JsonSlurper().parse(message.contentsAsBytes())
      // do something here that handles message
    }

    then:
    true

3. Builder merges message into pact file using provider state and description as the key (potentially call to pact ruby CLI to convert the simple ruby pact JSON into the proper message format?)

Q. What triggers the writing of the message?

Provider

1. Iterate through each message a) set up state b) invoke provider code that is expected to produce the message (argument is the message description) c) perform matching of expected/actual d) tear down state

2. Pass/fail based on overall state

Potential itermediate solution until we switch to Rust

Reuse pact-provider-verifier. Instead of user providing HTTP endpoints for the verifications and the state set up, they provide scripts.

eg.

pact-provider-verifier consumer-provider.json --provider-script provider.js --setup-script setup.js

Argument to the provider-script would be the message description. Argument to the setup-script would be either piped JSON (Q is this possible across platforms?) or key value pairs.

Thanks @alexeits and sorry we missed the comment (don't get notifications for Gists!). I'll raise with maintainers now on slack.pact.io

@mefellows Any update on this issue? We are looking to implement the AsyncAPI specification via Websockets and have an API which supports both Publisher/Subscriber and Request/Response patterns!

For which language @basickarl? Pact-JS and PactJVM currently support async messages.

bethesque Pact-JS and Pact-Node I was thinking! I apologize but the documentation and examples aren't very clear on how to make one consumer test and one provider test for 2 messages, one request with a payload and one response with a payload.

I would like to write 1 consumer test. The consumer opens a websocket, sends an object asynchronously. The consumer then waits for the response object on the same websocket connection from the mock pact server which it sends asynchronously after the mock pact server received the initial request object over a websocket asynchronously. In other words: asynchronous request-response pattern. Pact supports synchronous request-response from what I see and pub/sub pattern. But I'm talking specifically about asynchronous request-response pattern.

I would like to write 1 provider test. The provider hosts a websocket server to which the mock pact client joins to, the mock pact client then sends an object asynchronously via that websocket. The mock pact client then waits for a response object from the provider which the provider will send asynchronously.

The two tests above can be written in Pact pretty easily, but there is no information how to do this asynchronously via websockets. In the REST consumer test you would define an interaction with withRequest and willRespondWith, but those are specific to REST. I would like the following but tailored to a websocket transferring objects back and fourth over the open websocket connection.

@basickarl want to hop on slack.pact.io and chat about it there?

@bethesque Absolutely!