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
Thanks to comments from @FND this now has a more useful structure
that orders and separate things by topic and complexity.
* introduce the general topic
* say how to use existing handlers
* explain how to create them
This is an improvement but I'm not certain it is yet perfect.
That's okay. If it is good enough we can move forward and move
it in the direction of perfect later.
If $LAST_URL is used anywhere a replacer is accepted, it will
be replaced with the URL from the previous test.
At the moment the URL is the full url that is passed into the http
client. Thus it includes the scheme, the netloc and any query
parameters that may have been added by the use of the
`query_parameters` test key.
It's not certain that this is the right choice. The other option is
to use the value of `url` that is in the test input. The is what's
actually the value of the url or {GET,POST,..} key in the test.
This is problematic though as there are at least two ways this could
be interpreted:
* the literal string that is in test['url'] in the test data
structure
* that string after replacers have been run
Using the final full URL seems to suit the use cases I can think of
and feels somehow less ambiguous so that's what I implemented, but
it too has some issues:
* If $LAST_URL has query parameters in it, trying to _replace_ (not
extend) those parametes via `query_parameters` doesn't really work.
There's a failing test to demonstrate this problem.
(there may be others I haven't thought of yet)
Input desired from @FND and others please.
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.
This may not be fully adequate but is a reasonable start. The main
point was to indicate the different loader method and the need
to yield the generated tests.
This feature was effectively already there but not fleshed out in
tests nor documentation. Now there are some tests and a short
piece of documentation with a light warning about avoiding overuse.
A slight adjustment was required in data handling to deal with
empty lists and empty objects.
Fixes #113
