Support other body types than JSON

[pact-foundation]

Support other body types than JSON

[bethesque]

This might help us

https://github.com/mbklein/equivalent-xml

But I'm not sure that it gives a diff, possibly just says whether they're equivalent or not. But it might be a useful building block.

[bethesque]

@thetrav and @uglyog. We should start working out an XML support battle plan, so that when someone comes to implement it, we have at least a rough idea of how to make it work.

As I see it, our options are:

1. Embed the XML inside a JSON document in the body node.
2. Embed the match information as xpaths.
3. Create an XML pact.

Thoughts?

[paulhenrich]

I have a need to implement this for a project I'm working on where we are driving new soap endpoints. As a first go, I just shoved the escaped XML into the 'body', which of course works when we have an exact string match. I'm thinking of sticking with that approach (xml in the json pactfile) but using equivalent-xml (thanks for the pointer) to match in the request dispatch.

Any thoughts on this? Ideas on where to start?

[bethesque]

Yay! I have lots of thoughts. Firstly, let me do a quick refactor so that the differ can be configured based on content type. Secondly, while I'm doing that, have a look at the pact-specification repo, and have a think about the matching rules we want to use, based on the principles of "be strict with what we send out, and relaxed with what we accept". Thirdly, fork this repo https://github.com/bethesque/pact-xml Fourthly, fourthly sounds like a stupid word. Fifthly, if you're still up for it, implement the Differ and DiffFormatter with lots of lovely specs.

Lots of people have asked for this feature, so it will gain you lots of nerd karma if you pull it off. Lets keep "touching base" (wanky phrase alert) as you go (if I haven't scared you off. It's really straightforward, promise...)

[paulhenrich]

Thanks. That's awesome.

I started digging around in rack_request_helper to branch off for different content types. It's quite dirty right now, just to kind of get my head around the cycle and have some very basic xml->object hydration working.

I learned late yesterday that I have to get approval on this particular project/client to contribute upstream to OSS projects, so I'm working on that. Hopefully it won't be a problem.

[bethesque]

Ok, finger's crossed! You're not thinking of using Nokogiri?

[paulhenrich]

No thoughts at the moment on using Nokogiri. For the first stab I just used active support to_hash because it was there. I'm guessing you mean because Nokogiri would be pretty heavy-weight & you don't want to bring it in as a dependency?

[bethesque]

I have no problem with Nokogiri - equivalent-xml uses Nokogiri, which is what I thought you were planning on using. I wasn't sure why you were looking at doing custom parsing of the xml?

I'd actually prefer Nokogiri to ActiveSupport! ActiveSupport messes with the serialisation of the pact as it rudely overrides the to_json methods of various things without asking. If you have a look at the codebase, you'll find my ActiveSupportSupport code - the code you need to support you when you're using ActiveSupport!

[paulhenrich]

What I'm doing right now parallels the json path—hydrate & then diff the ruby objects. Does that seem like an approach that would work for the project? First-class XML diffing & diff printing seem like much harder problems that I don't think I can take on at this time.

[bethesque]

I haven't given it serious thought, but the first idea that popped into my head is that you'd parse both the expected XML and actual XML to Nokogiri documents, then step though the expected tree (the same way the json diff does) and compare the current node (and attributes) to the actual node (and attributes). It sounds like the same thing as you're doing, but using Nokogiri as the hydrated Ruby object.

You do make a reasonable point about including Nokogiri as a dependency. If you think it would be just as easy without it, then go for it. Are you thinking of reusing the json diff code, or copy/modifying it? I guess the XML attribute checking logic means you can't reuse it.

[bethesque]

Done. See https://github.com/bethesque/pact-xml for example.