{"action":"created","issue":{"url":"https://api.github.com/repos/cdent/gabbi/issues/45","labels_url":"https://api.github.com/repos/cdent/gabbi/issues/45/labels{/name}","comments_url":"https://api.github.com/repos/cdent/gabbi/issues/45/comments","events_url":"https://api.github.com/repos/cdent/gabbi/issues/45/events","html_url":"https://github.com/cdent/gabbi/issues/45","id":88824774,"number":45,"title":"$RESPONSE and json_response_paths fail if content-type isn't JSON","user":{"login":"kiminoa","id":173422,"avatar_url":"https://avatars.githubusercontent.com/u/173422?v=3","gravatar_id":"","url":"https://api.github.com/users/kiminoa","html_url":"https://github.com/kiminoa","followers_url":"https://api.github.com/users/kiminoa/followers","following_url":"https://api.github.com/users/kiminoa/following{/other_user}","gists_url":"https://api.github.com/users/kiminoa/gists{/gist_id}","starred_url":"https://api.github.com/users/kiminoa/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kiminoa/subscriptions","organizations_url":"https://api.github.com/users/kiminoa/orgs","repos_url":"https://api.github.com/users/kiminoa/repos","events_url":"https://api.github.com/users/kiminoa/events{/privacy}","received_events_url":"https://api.github.com/users/kiminoa/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-06-16T19:53:31Z","updated_at":"2015-06-16T21:59:28Z","closed_at":null,"body":"Probably a feature request ...\r\n\r\nRight now, our API supports XML and JSON and we'd ideally love to just toggle between the two. \r\n\r\nBecause of the way gabbi does the response_strings, and using $ENVIRON in the defaults: for content-type/accept, we can so almost pull this off.\r\n\r\nTwo places where the fancy idea fails:\r\n1. Any use of $RESPONSE with an XML content-type response will result in:\r\n```\r\n----------------------------------------------------------------------\r\n_StringException: Traceback (most recent call last):\r\n  File \"/Library/Python/2.7/site-packages/gabbi/case.py\", line 78, in wrapper\r\n    func(self)\r\n  File \"/Library/Python/2.7/site-packages/gabbi/case.py\", line 118, in test_request\r\n    self._run_test()\r\n  File \"/Library/Python/2.7/site-packages/gabbi/case.py\", line 291, in _run_test\r\n    base_url = self.replace_template(test['url'])\r\n  File \"/Library/Python/2.7/site-packages/gabbi/case.py\", line 132, in replace_template\r\n    message = getattr(self, method)(message)\r\n  File \"/Library/Python/2.7/site-packages/gabbi/case.py\", line 253, in _response_replace\r\n    self._json_replacer, message)\r\n  File \"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/re.py\", line 151, in sub\r\n    return _compile(pattern, flags).sub(repl, string, count)\r\n  File \"/Library/Python/2.7/site-packages/gabbi/case.py\", line 202, in _json_replacer\r\n    return str(self.extract_json_path_value(self.prior.json_data, path))\r\nAttributeError: 'test_env_loader_env_notes_add_environment_note' object has no attribute 'json_data'\r\n```\r\n2. `json_response_paths:` can't be used and ignored when XML or non-JSON is detected. It would be lovely if this was possible. It'd be nice to get some \"bonus\" JSON tests when JSON is detected, and ignored with a warning otherwise."},"comment":{"url":"https://api.github.com/repos/cdent/gabbi/issues/comments/112581031","html_url":"https://github.com/cdent/gabbi/issues/45#issuecomment-112581031","issue_url":"https://api.github.com/repos/cdent/gabbi/issues/45","id":112581031,"user":{"login":"cdent","id":34498,"avatar_url":"https://avatars.githubusercontent.com/u/34498?v=3","gravatar_id":"","url":"https://api.github.com/users/cdent","html_url":"https://github.com/cdent","followers_url":"https://api.github.com/users/cdent/followers","following_url":"https://api.github.com/users/cdent/following{/other_user}","gists_url":"https://api.github.com/users/cdent/gists{/gist_id}","starred_url":"https://api.github.com/users/cdent/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cdent/subscriptions","organizations_url":"https://api.github.com/users/cdent/orgs","repos_url":"https://api.github.com/users/cdent/repos","events_url":"https://api.github.com/users/cdent/events{/privacy}","received_events_url":"https://api.github.com/users/cdent/received_events","type":"User","site_admin":false},"created_at":"2015-06-16T21:59:28Z","updated_at":"2015-06-16T21:59:28Z","body":"If I'm understanding what you're saying the idea is that it ought to be possible to have $RESPONSE['$.stuff'] and response_json_paths in a test but for them to only be engaged if the content type on the associated test is JSON.\r\n\r\nOn the one hand I can see the appeal of this, done properly it would let you have a single set of tests that operates properly under a variety of circumstances.\r\n\r\nOn the other hand I'm not super keen: It would result in tests that contain assertions that only apply in some circumstances, circumstances you (as a reader) can't know while reading the tests. This would kill one of the main design goals of Gabbi: readable and fairly unambiguous tests.\r\n\r\nThat said, I think there are probably ways for you to accomplish something similar to what you want:\r\n\r\n> Given that tests are YAML and lots of things are YAML you could write some base tests and a processing tool which read the YAML as input and output yet more YAML, some of which is tests for XML and some of which is tests for JSON. If you combined this with a response_xml_path handler that you wrote you'd have some pretty powerful tests that also happened to be reasonable artifacts.\r\n\r\nThat leaves open how to deal with RESPONSE handling of XML, which is probably a useful and warranted feature. I'd certainly be willing to review (and most likely) accept patches that added support for that but XML is not something I use in day to day work so nothing something that is going to come up as an immediate itch for me.\r\n\r\nFinally, in your situation what I would probably end up doing is just writing (by hand) all the tests required for the different content types. Yes, this can feel like a lot of duplication, but it results in a collection of tests which are clear artifacts that describe the system being tested. I'm not opposed to automation at all but I think that there is a lot of temptation to automate the wrong things. Reading and writing tests is really for humans."}}