Hello! I saw in the pact docs FAQ a topic about points with Swagger, and it said to contact one of the maintainers if you are interested in doing something like generate a Skeleton Pact test code from a Swagger document. Do you already have something thought about this? Who can I contact about it?

Hey @Rubem Ferreira , Welcome! Very cool idea, it’s been on want list for many a moon. First off I’d start with some terminology. OpenAPI, is formerly known as Swagger, with Swagger now referring to tools used to interact with Open API Documents/Specs referring to the document in yaml or Json. I’m curious but unsure of the intristic value, in the real world. I know that swagger-codegen will allow for generation of both servers and client sdk’s. The client sdk’s actually having at least stub tests in place for a unit testing framework. It isn’t too much uplift to scaffold a basic pact test, in which the consumer could then record their expectations when they decide what they want to consumer on a particular providers endpoint, or remove anything they don’t wish to consume. I wonder how many people use the codegens, and how well they help over time as a service evolves, and you have had to augment the initial generated client code. Both myself and @Timothy Jones have discussed vscode snippets for each of the pact languages so it if easy to create the boilerplate for an interaction in any given language. I hacked out how we could incorporate consumer expectations into an openAPI spec and generate consumer contract files ( pacts ) off the back of it. These could be replaced by the real expectation in the future, when the consumer code is created. I think @Matt (pactflow.io / pact-js / pact-go) would also be interested in this conversation. Love to hear your thoughts and what you’ve got up to so far, if anything :)

When I started with pact, this is something that I wanted. However, it’s worth pointing out that: • the point of pact is not to describe the whole api, but to describe only the parts that the consumer is using. So, if you did pact-from-swagger, it would probably describe too much and you would lose some of the advantages of pact. There would be some use cases for people who create the swagger for exactly one client, but over time as the api changes think it would produce unnecessary maintenance of dead code • A disadvantage of swagger is that it doesn’t have clear mapping between requests and responses (and there are a few other challenges generating examples from swagger), so I’m not sure how this would work. Of course, just because I can’t see how it would work doesn’t mean it doesn’t work

Yep 💯. The main use case and supporting argument for this is to reduce boilerplate code and really nothing else. The risk runs the other way of course (now you might over specify requests etc. and the above context may get lost, which is something that needs careful consideration - documentation will not solve that problem)

Thank you all for the contribution, it was enlightening. I'm maturing the idea, and when I have something more concrete I'll get back in touch!