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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev