-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In 'live' testing scenarios argument passing to build_tests is convoluted and SSL may not work #50
Comments
See also #105 which has related ssl things to say. I suppose one way to do this is to add yet another argument ( Such a lot of arguments though... |
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.
There's still part of this which is not done, which is just passing the url to gabbi instead of parsing beforehand. |
One option for doing this that wouldn't need to extend the method signatures even more would be to have something like a Opinions? |
The value of url overrides host, port and prefix if it is set. This will make some live testing scenarios more straightforward. Fixes #50
The value of url overrides host, port and prefix if it is set. This will make some live testing scenarios more straightforward. Fixes #50
The value of url overrides host, port and prefix if it is set. This will make some live testing scenarios more straightforward. Fixes #50
If you want to use
build_tests
to create real TestCases against a live server it's likely you know the URL and that would be most convenient thing to pass instead of having to parse out the host, port and prefix (script_name) and then pass those.In addition, if you have a URL you know if your server is SSL but the tests may not have been written to do SSL (with an
ssl: true
entry). Because of the test building process this is a bit awkward at the moment. It would be better to be able to say "yeah, this is SSL" for the whole run.The text was updated successfully, but these errors were encountered: