Good news! Last week's contract testing talk went down very well at work amongst the engineering practice. In the new year we are going to run a proof of concept. A lot of the services we use are SOAP, what does Pact have to say about contract testing SOAP?

WSDLs have the same kinds of issues as OAS, or other schema specs: less reasoning power (aka: schemas are not contracts)

WSDLs do have a small benefit in that you can generate code that will always (un)marshall correctly, but you can't guarantee that everything that is expressed is valid.

To some extent I could see it working similarly to bi-directional contract testing, in that the contract must be a subset of the WSDL. But I’m not sure how much benefit you get from this in the same way you do with HTTP. Keen to be wrong on this tho

Yeah. We do have this on our list for BDCT, but I’m not yet convinced we’ll actually be able to solve the problem. In my experience, and some of the examples I’ve seen, the schemas are so full of “optional” elements, that almost any XML document would match. Which, obviously, wouldn’t be too helpful 😆. But that may not be a reason to not do it for those that have useful schemas. I think schematron could also play a part here, which alleviates many of the problems XSD had (in practice, not theory). So the way BDCT works with OAS now, whilst suffers from a variant of the same problem, is nowhere near as bad.

Thanks both, very useful. Yeah, I also see with SOAP services that we use there are tons of optional elements, which means the utility of applying any form of rigour to them is very limited. I've had some success with snapshot testing on the client side using Jest, so we can capture the SOAP we are sending and check it isn't unintentionally drifting. That says nothing about the validity of the SOAP request against the schema so we have to trust there. It's at least a step forward though