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

Plan to support Pact v4 #45

Open
swimclan opened this issue May 16, 2024 · 2 comments
Open

Plan to support Pact v4 #45

swimclan opened this issue May 16, 2024 · 2 comments
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed

Comments

@swimclan
Copy link

Hi! Thanks for this useful library!

Would there be any plan in the near future to migrate support to 4.0? We are trying to use the Java adapter for the provider side and the validation method seems to default to 4.0 which is causing some incongruence with our process.

Thanks again!

@YOU54F
Copy link
Member

YOU54F commented May 16, 2024

👋🏾 Hey Matthew!

Thanks for this useful library!

Glad you find it useful, feedback is always good :)

We are trying to use the Java adapter for the provider side and the validation method seems to default to 4.0 which is causing some incongruence with our process.

Pact-JVM should support verifying up to and including V4 pact files, so that sounds like a separate issue best raised in the pact-jvm project.

Would there be any plan in the near future to migrate support to 4.0?

With regards to supporting additional specifications in the adapter, it would be preferable to at some point support V4 in all of our languages by default. We have been making good strides in bringing the clients libraries. The adapters are a bit of a periphery, the main use case is in bi-directional contract testing, where the generated contracts are statically compared against an OpenAPI document. The tool used for comparison supports V2-V4 Pacts, but doesn't support traditional CDCT techniques such as provider states or matchers (schema matching is performed by default).

That being said, the route to V3/V4 spec in the adapters, is certainly manageable for someone as a community contribution

general adapter guidance:- https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/pact#converting-mocks-into-a-pact-compatible-format

pact v4 spec compat:- https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/pact#supported-pact-specification-versions

See caveat about v4 pacts

The pact serialisation function is here

export const constructPactFile = ({ intercept, testCaseTitle, pactConfig, blocklist = [], content }: PactFileType) => {
const pactSkeletonObject = {
consumer: { name: pactConfig.consumerName },
provider: { name: pactConfig.providerName },
interactions: [],
metadata: {
pactSpecification: {
version: '2.0.0'
},
client: {
name: 'pact-cypress-adapter',
version: pjson.version
}
}
}

which creates the structure which adheres to a pact v2 specification.

we provide typed schemas for the pact specification here

https://github.com/pactflow/pact-schemas

which can be used to validate the created pact if required (can definitely help during development)

We would want to expose an ability to set the pact specification version, and have it default.

@mefellows mefellows added enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed labels Oct 9, 2024
@mefellows
Copy link
Contributor

Thanks @swimclan, the purpose of this is to work with PactFlow's BDCT feature (as noted) so we only require a minimum of v2 for this - but v4 support should be fairly straightforward if you'd (or somebody else) would like to add it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants