Proposal: Improve the Pact DSL to play better with test frameworks and reduce repeated code

[TimothyJones]

Test frameworks for Javascript are diverse - some run in parallel by default, some have different testing styles or expectations (eg BDD), and they all have different ways to configure and instrument the test framework.

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.

Lastly, Javascript Pact tests are very verbose with a lot of repetition. It would be an improvement to be able to write concise tests with less repetition.

I've written up a gist that contains a three stage proposal to improve this:

https://gist.github.com/TimothyJones/d138bf765509d41e0ce8a4bfb777a31d

[mefellows]

Thanks again for this Tim. I have left some comments on the gist which is a very brief reflection of my current thinking.

[TimothyJones]

I've been thinking more about this. For Jest, I've been using the following:

const pactWith = (options, tests) =>
  describe(`Pact between ${options.consumer} and ${options.provider}`, () => {
    const pactMock = new Pact({
      port: options.port || 8989,
      log: path.resolve(process.cwd(), 'logs', 'mockserver-integration.log'),
      dir: path.resolve(process.cwd(), 'pacts'),
      spec: 2,
      pactfileWriteMode: 'update',
      ...options,
    });

    beforeAll(() => pactMock.setup());
    afterAll(() => pactMock.finalize());
    afterEach(() => pactMock.verify());

    tests(pactMock);
  });

This lets you write:

pactWith({ consumer: 'MyConsumer', provider: 'MyProvider' }, provider => {
    // regular pact tests go here
}

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.

[mefellows]

☝️ looks really nice!

[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]

Closing this as no longer relevant (newer API released, jest-pact/mocha-pact etc. exist)