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
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.
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
After much discussion this was determined to be the easiest and
cleanest way to accomplish a test which asserts "this header must
not be present". The ResponseHandler framework is used to good
effect to make short code.
The value of the response_forbidden_headers is a list of headers.
Case will be normalized to lower, which matches the internal
representation of the response headers dictionary.
Fixes #108
Originally there was no tests dir. When unit-like tests were added
they were put in a newly created tests directory. Since it is there
may as well use it.
previously keys were documented as a lengthy list in seemingly arbitrary
order - in contrast, this structure promises to be more comprehensible
(and less daunting), plus table layout should improve readability and
scannability by providing some visual consistency
note that this inevitably led to various editorial changes
This adds a query_parameters field which can be used to add query
parameters to the url of the test in which it is used. It is a dict in
a form suitable for being passed to the urlencode() method.
This change is cumbersome because urlencoded in python2 and 3 have
different behaviors: In python2 a utf-8 encoded string is required.
In 3 it will figure out the right thing. So we here we just encode.
We also need to deal with the fact that a numeral in YAML will be
provided to Python as a numeric value and we need to stringify that in
a version independent fashion.
Until this change only response bodies with a content-type of
'application/json' were decoded from JSON and stored in the
json_data attribute. Now '+json' style content-types also get the
same treatment.
json_data is the attribute later used when checking
response_json_paths. An expectation of a correct content type has
always been present but the docs have been update to make this
clear.
In the future when other content types will have handling similar to
JSON, this processing will need to be encapsulated in the
implementations of each content type handler. This fix is short
term.
A prefix is applied to all the unqualifed URLs in a suite of tests.
This is useful for testing live applications that are mounted at
different points under a wsgi server.
Fixes #46
The assumption is that when using those strings we actually want
booleans, additional there are a few BASE_TEST keys for which the
value is expected to be boolean and using an environment value
(which would always be a string if used directly) will not work (as
there is no way to indicate False).
Fixes #40
