Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
TimothyJones opened this issue Oct 2, 2018 · 4 comments

Comments

@TimothyJones
Copy link
Contributor

commented Oct 2, 2018

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

This comment has been minimized.

Copy link
Member

commented Oct 18, 2018

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

@TimothyJones

This comment has been minimized.

Copy link
Contributor Author

commented Nov 9, 2018

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

This comment has been minimized.

Copy link
Member

commented Nov 23, 2018

☝️ looks really nice!

@stale

This comment has been minimized.

Copy link

commented Feb 10, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.