Provider state parameters not implemented

[kneczaj]

Software versions

• OS: Windows 10
• Consumer Pact library: @pact-foundation/[email protected]
• Provider Pact library: does not matter
• Node Version: v10.15.3

Expected behaviour

The state parameters can be passed, like at pact 3 specification
https://github.com/pact-foundation/pact-specification/tree/version-3#allow-multiple-provider-states-with-parameters

Actual behaviour

A provider state can be defined by string only.

Steps to reproduce

See the interface used to define an interaction that it can only receive a string for provider state

pact-js/src/dsl/interaction.ts

Line 28 in 3d66117

state: string | undefined

Relevant log files

none

I am in a project which used to be consisted of Java services only which have defined many providers with parameters. With pact-js I cannot reuse these providers.

[mefellows]

Thanks. We know this is lacking as it is a v3 feature. I'm going to create a separate issue later tonight to track the v3 implementation, but work is already underway (see the v3 branch).

[kneczaj]

@mefellows thanks a lot!

[straurob]

Is there any way to work around this with the v2 specification?

Example:
The consumer test registers a new user using her email address [email protected]. The provider state setup function must execute a query to make sure that the email address does not exist yet.

[bethesque]

The better way to handle that solution is that the datasources should all be cleared at the start of the provider state set up call. Then you would know that it does not exist.

[mefellows]

As Beth said. But also, you could have two separate tests and states

e.g.

• "... when user [email protected] exists"
• "... when user [email protected] does not exist"

You don't need a state parameter to do this.

[garry-jeromson]

Are there any plans to make the library compatible with v3.0 state parameters? When you only have one variable, adding two tests is fine, but with several variables you end up needing N-factorial state resolvers on the provider side, which is really a pain.

For example, we have a multi-tenant application, and using pactman we can structure our Python consumer tests to have states like:

...
"providerStates": [
        {
          "name": "a tenant exists with the given tenant ID",
          "params": {
            "tenant_id": 1
          }
        },
        {
          "name": "a doctor with the given ID exists",
          "params": {
            "doctor_id": 123,
            "tenant_id": 1
          }
        }
      ],
...

We can't yet do this for our JavaScript/TypeScript clients without creating clunky-as-hell states like Given that a doctor with ID 123 exists on tenant with ID 1 and his favourite colour is turqoise, etc. This effectively means writing a new state resolver on the provider for every single test.

[garry-jeromson]

OK, just stumbled on this: https://github.com/pact-foundation/pact-js#pact-js-v3 - looks promising.

[mefellows]

Yes, that should do the trick for you Garry! Please also note the new package import too - we'd love your feedback on this too.

…

On Mon, 29 Mar 2021, 8:30 pm Garry Jeromson, ***@***.***> wrote: OK, just stumbled on this: https://github.com/pact-foundation/pact-js#pact-js-v3 - looks promising. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#372 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANFDBDYTD3YAMQ4M4DRJTTGBJDBANCNFSM4I5NWBCQ> .

[garry-jeromson]

First impression is: it's gonna be a tricky migration, at least for our setup (consumer tests only, Jest + TypeScript). The interface for the PactV3 class is very different to the Pact class (from here) so it's not gonna be as simple as just tweaking the state parameters, and will require a bit of a rejig of our whole setup. More digging required. 🧑‍💻

[mefellows]

Thanks @garry-jeromson. We're looking at bringing that more inline with the current type definitions, but there is going to be a lag there.

In the meantime, I believe #407 might actually work - it's just not tested and the author has gone stale. It could also potentially be added to the existing interface and might work (again, needs testing, but the underlying engine does actually support multiple states for message pact, so it's possible the http interface already supports it, but it's not exposed to the DSL itself).

cc: @TimothyJones

[mefellows]

10.x.x now supports this.

[adamwitko]

@mefellows on reading the V3 spec, I just wanted to check, is provider state parameters only supported for message based pact testing and not the standard verifications?

[mefellows]

It should be supported for all interaction types.

[adamwitko]

It should be supported for all interaction types.

I checked the merged PRs above and state params have been added for the message provider and not others. The spec also seems to focus on message pacts when talking about state params so I'm a little confused :D

I couldn't spot any state param options for 10.x.x.

[mefellows]

It should be there, see https://github.com/pact-foundation/pact-js/blob/master/src/v3/pact.ts#L69.

Example e2e test:

pact-js/examples/v3/e2e/test/consumer.spec.js

Lines 399 to 401 in aecc39e

	.given('Has an animal with ID', {
	id: 100,
	})

Here is the corresponding provider example that accepts them:

pact-js/examples/v3/e2e/test/provider.spec.js

Lines 48 to 55 in aecc39e

	'Has an animal with ID': (parameters) => {
	importData();
	animalRepository.first().id = parameters.id;
	return Promise.resolve({
	description: `Animal with ID ${parameters.id} added to the db`,
	id: parameters.id,
	});
	},

[adamwitko]

Ok thanks @mefellows. I'll go and figure out if I'm a fool and I somehow missed it 👀

[mefellows]

haha no worries!