load_data_file is used to read a chunk of JSON from disk. For many
people this will be most useful when validating an entire JSON response,
but in some cases it could be useful for a smaller piece.
Docs to follow.
This change implements template substitution ($ENVIRON, $RESPONSE,
etc) in the left hand side of a response_json_paths test. This enables
testing in situations where responses may include a server side
generated identifier as the key in an object structure.
As things stand, this is the bare minimum implementation that assumes
that the test creator will be responsible for dealing with the
vargrancies of quoting that will be required in order to generate
legitimate JSON path expressions. For example if there is a uuid (with
hyphens) at $RESPONSE['$.id'] then this expression is likely to fail:
$.nested.structure.$RESPONSE['$.id'].name: foobar
as it will evaluate to something like
$.nested.structure.ADC8AAFC-D564-40D1-9724-7680D3C010C2.name: foobar
which _may_ be treated as an arithemtic expression by the json parser.
The test creator would need to do:
$.nested.structure["$RESPONSE['$.id']"].name: foobar
or variants thereof to get a useful expression.
Docs to follow if this is considered an okay way to implement the
feature.
Fixes #170
Change the handling in response_replacer and jsonhandler.replace so
that numerals are preserved. The primary change here is that replace
does not always return a str: it returns the found data. The
remaining changes cascade from this fix.
* If the 'message' being replaced is fully the regex, don't do
regex-based replacement (which requires a string). Instead return
the new value.
* Do template replacing on test data _before_ dumping it to a string.
This allows the small 'message' replacements described in the previous
point.
* Assure we can recurse through lists, not just dicts, when
replacing in data structures.
In the pull request at #206 there is a different mode of coercing
and preserving data types operates by adding a coerce method to
content handlers. While inspecting this it seemed like it might be
too complex, so this alternate option has been explored. This might
work, or perhaps a hybrid of the two.
The coerce.yaml file from #206 was copied here and adapted to fit
the different assumptions that are made in this change. Some of the
assumptions in 206 don't map well to YAML handling of literal data
formats.
Add optional `test` param for custom content handlers
This resolves #211.
`multipart/form-data` transmission requires modifying the `Content-Type`
header with a `boundary` section identifier, and as such a custom
content handler would not have previously had access to the running test
case it was working on. This should hopefully be useful for other custom
content handlers in the future.
Regex handlings was added to the right hand side of json path
expressions. This updates the content-handlers branch to support
them and merges up to master.
In the process of writing, some slight adjustments to the interface
were made:
* ContentHandlers direcly inherit from ResponseHandler rather than
doing a Mixin. This makes it easier to create your own.
* Rather than defining gen_replacer, a subclass defines replacer,
which gen_replacer calls.
The documentation is challenging to get right. I suspect there are
many improvements that could be made to make it more informative
and easier to follow. I think I'm probalby too close to it. @FND
will likely have some useful suggestions.
Still todo: docstrings on the new classes.
