Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: Improve the Pact DSL to play better with test frameworks and reduce repeated code #215
The Pact workflow also includes a number of (necessary) assumptions and expectations - such as the need to keep interactions separate in the mock provider (meaning tests can't run in parallel) and the need to spin up the mock server at an appropriate time (meaning that the Pact file write mode needs to be set correctly for each framework). These don't always play nicely with the JS test framework.
This means that using Pact effectively (or sometimes at all) requires extra understanding of how Pact and your chosen test framework work and interact, beyond the necessary understanding to simply write a consumer test. It would be an improvement to change Pact workflow so that this additional understanding is only necessary in unusally complex setups.
Another potential source of confusion is that Pact's current implementation gets information and configuration from custom scripts called in different parts of the test and development lifecycle. This is unusual for node projects - most of which are configurable by their own named settings files or a key in package.json.
It would be an improvement to change to a more idomatic node configuration method. This would also have the advantage that different test frameworks would still have similar pact setups.
I've written up a gist that contains a three stage proposal to improve this:
I've been thinking more about this. For Jest, I've been using the following:
This lets you write:
It could be a straightforward extension to have the function allocate ports that don't collide, meaning that Jest's parallel execution wouldn't be a problem.