Pact-js: createMessage support is missing from pact-web

[alexeits]

Software versions

• OS: macOS 10.13.6
• Consumer Pact library: @pact-foundation/[email protected]
• Provider Pact library: N/A
• Node Version: v8.10.0

pact-js installs pact-node 6.0.x and pact-web 5.9.1, which doesn't have support for asynchronous pacts / createMessage API.

Are there any near future plans to add createMessage support to pact-web?

[mefellows]

Thanks @alexeits. The short answer is "probably not".

Pact Message requires executing binaries on the file-system, which pact-web by it's very nature doesn't have access to. It also needs to spin up an HTTP proxy server on a dynamic port to communicate with those processes, which can't be done in non-Node environments.

I've been thinking for a while now about pact-web. Whilst it's useful for the karma/in-browser use case, I'm not convinced most people can't just create a separate testing setup for contract tests that has access to a full node environment.

It's all just JS, and if you can't split out the parts of your code that talks to the provider from your front-end framework, then it's probably not designed very well in the first place.

I suspect these are the two motivations that might keep pact-web alive, and I have more empathy for the second (e.g. retrofitting pact test cases onto a legacy / old system might be an appropriate strategy to help with refactoring code)

It is probably technically possible to make this happen by other means, and i'm open to implementation suggestions, but I certainly don't want it to make the DSL/user interface any more complicated for users and I'm not sure we can completely avoid that.

Thoughts?

[alexeits]

@mefellows I can see your point. It's definitely possible to extract pact tests into a separate suite and run them in node.js.

In my situation it isn't necessarily the most straightforward thing to do though. All of our JS tests are currently run in-browser continuously upon every change and developers don't need to leave the browser to see the result of their changes. They keep switching between the editor and the browser or place them side-by-side if they have a large monitor. With pact tests run in node they will also need to look in the terminal, which adds another window to watch and that would require some retraining / getting used to. OS notifications / growl could reduce that need but in my experience most people prefer to see the progress "dots" of tests being (re)run.

As a side note on pact-web, while message pacts could be verified in node.js, I don't think there's a good alternative for HTTP request-response pacts due to the lack of XHR in node.

My preference would be to have support for createMessage in pact-web. Although we would run pact tests in node if we had to. We can experiment and report back.

Off-topic: at the moment I think a bigger issue for pact-js adoption in our organization is a one-way nature of message pacts. The majority of our messages are request-response and setting up two pacts for them is likely going to be cumbersome. Are optional responses to the messages still being considered?

[mefellows]

Thanks, I think there are a few good points here. We just need to weigh up how we make it all work, whilst reducing the amount of frameworks and tools we need to support to enable the various workflows.

...The majority of our messages are request-response and setting up two pacts for them is likely going to be cumbersome

Can you elaborate - do you mean things like HTTP2/WebSockets, or do you mean request-response in the message queue nomenclature, whereby there is a long-lived queue that intermediates a request-response cycle?

[alexeits]

there is a long-lived queue that intermediates a request-response cycle

I think this ☝️description fits best. As I mentioned in another comment we use MQTT over WebSockets to communicate with backend. Many of our messages sent by client could be considered "requests" because they have corresponding "responses". They go to different queues / topics that follow a certain naming convention and they also have a correlation id so that client gateways know how to match responses to requests.

We have our own contract testing solution that captures such request-response pairs in a single contract file and we are looking to replace our contract testing framework with Pact tools.

[mefellows]

Thanks, i'll chat with other Pact-ers and to their collective wisdom.

[mefellows]

See https://gist.github.com/bethesque/c858e5c15649ae525ef0cc5264b8477c for some further background.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mefellows]

At the moment, we don't have any plans to introduce this into pact-web. It doesn't align with our vision of using a central library (written in Rust, currently in Ruby) and I can't see how we can easily add support with the current system. It's possible that at some future point in time something like Web Assembly will make this possible, but for now it's a huge amount of work (implementing the entire set of pact specifications to run in a browser).

I'm very much open to implementation suggestions, but at the moment it's not possible unless we can open up a port/endpoint dynamically in a browser (which to the best of my current knowledge, is not possible).