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.
Running just one dynamically generated test can be a bit confusing
so some advice is added to the faq. At some point this should
probably be intergrated into the mainline docs.
* allow pathnames when using <@ data loading syntax
* add --verbose to gabbi-run
* add a new technique for loading tests in pytest to avoid yield
test warnings
The details of how things works when data is a non-string were
not correct. When fixing that it became clear that the information
would make more sense presented as a list. So now it is.
loader.rst has been expanded to explain both ways for loading
tests using pytest, hopefully with sufficient context to explain
why it is like it is.
With any luck this will help make the obvious cleaner solution
more apparent as we iterate into the future.
A value of 'all', 'headers' or 'body' will have the expected
effect on all the tests being run in the current testing session.
This is done by manipulating the 'defaults' of each test suite.
Fixes: #185
This gets the basics in a very simplistic fashion.
What's missing is any indication of the availability of this feature
in the argparse created help (the output one sees from
gabbi-run --help). It's not clear what the best way to add this is,
since the feature is being managed outside argparse.
Add a faq.rst and two simple questions to get the ball rolling
on having a gabbi faq in the docs.
This format probably won't scale in the long run, but is useful in
the short run and while the format might become lame the content
will not.
If the value of jsonpath entry is a string and is wrapped in /.../
then the matching of the results of the jsonpath will be check via
the regex.
Fixes #146
Some recent failulres in OpenStack land made it clear that
it was less clear than it should be the precautions that are
required when running gabbi in a concurrent testing environment.
The idea is to have informal (but hopefully useful) entries on
this page when something interesting happens. I've filled it in
with all the relevant releases since 1.0.0.
build_tests gains a require_ssl argument which, if set to True,
makes all the loaded test suites default to 'ssl: True'.
gabbi-run will interpret a target containing 'https' as meaning
that the tests in the provided yaml should default to 'ssl: True'.
Fixes: #50
Fixes: #105
Fixes: #138
The changes here are the naive basics to get the desired behavior.
There's an existing cleanup branch on which we can clean this up
later.
According to rfc 2732 an IPv6 address in a url needs to be enclosed
in [] (e.g. http://[::1]/foobar). Gabbi was not doing this. Instead
it was passing host information directly to its URL generation
routine and just using it. When doing tests against real servers
running on ipv6, this results in failures.
The changes here try to do the bare minumum to get the right results
without changing the create_url method too much. It's likely that in
some future version of gabbi we will want to change a lot here (the
current orientation towards hosts and ports instead of URLs is the
result of the wsgi-intercept integration) but for now we want to
keep the change limited.
I hate myself for the mocks in test_runner. A clear sign of bad
abstraction in runner.py, however this is not the place to be
changing that. Another item for the later list.
Fixes #136
