Open Stack

On Mon, 12 Jan 2015, Sean Dague wrote:

> I think it's important to look at this in the narrower context, we're
> not testing full environments here, this is custom crafting HTTP req /
> resp in a limited context to make sure components are completing a contract.

Yes, exactly.

In fact one of the things that keeps coming up in conversations is
that people keep asking about ways of extending the response body
validation and I'm reluctant to make that aspect of things _too_
powerful. The goal is to validate that the HTTP is doing the right
thing, not to validate the persistence layer or the business logic
that is assembling the details of the resources.

In that sense the place where the attention and power should be in the
tests is in the crafting of the requests and in the validation of the
response headers. Part of the reason for including jsonpath was to be
able to do spot checks into the response body rather than including
some simulcrum of the entire response in the test.

And even including that was a matter of convenience to deal with
ambiguity in the JSON producers. The original response body tests
were simple assertions that some string fragment is somewhere in
the body.

-- 
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent