* upstream/master: (22 commits)
Regenerate authors.
Only run geolocation tests on CI
Switch to flake8-docstrings with pydocstyle
Fix lint
Move pylint plugins to an installed package.
Include pytest-xvfb properly in frozen tests
tests: Handle trailing / in wait_for_load_finished.
Fix lint.
tox: Upgrade hypothesis to 3.0.2.
tests: Add first end-to-end test for hints.
hints: Log the used hint chars
bdd: use quteproc.wait_for_load_finished.
Remove xvfbwrapper from freeze_tests.py.
Regenerate authors.
Combine launch/crash time into one section.
Split long lines.
Switch to pytest-xvfb. Fixes#1309.
no ellipsis is inserted in big windows
Regenerate authors.
fixes#1308
...
Trying to get the device location while running the tests can trigger all kind
of funny effects.
Since we can't easily mock the GPS responses, we only run those on the CI where
we at least have some predictable setup.
Fixes#1297.
This is based on HTML files with a global YAML comment, currently with "target"
as the only allowed key.
The tests then do this:
- Open a HTML file in data/hints/html
- Start hinting
- Make sure only one hint is visible
- Follow it, and make sure the page mentioned in "target:" is reached
Some ideas for the future:
- A "scroll" key, to scroll before hinting
- A "zoom" key, to zoom
- Multiple hints via a list
- Checking position of hints?
- A mode to manually check the pages (to check hint positions)
When a end-to-end test failed which would've marked an error message as
expected later in the test, seeing the teardown message about an unexpected
error being logged is really confusing.
For some reason, when comparing the repr in the two processes, we get different
results on OS X and Windows:
- expected: "fünf"
- "f\xfcnf" coming back from the subprocess on OS X
- "fnf" on Windows
Instead we're comparing the json dump now, which should be more predictable.
There are a lot of problems and flakiness with using a real clipboard.
Instead we now have a :debug-set-fake-clipboard command to set a text, and use
logging when getting the contents.
Fixes#1285.
Otherwise, if a test fails to actually put something into the clipboard, we end
up pasting "Does this work?" which could e.g. trigger a search.
When it's cleared, we at least get some "clipboard is empty" error instead.
In the long run, we should detect any accidental external accesses using
mitmproxy, as per #1282. In the meantime, we try to detect duckduckgo requests
being logged and fail the tests if that happens.
However, a duckduckgo URL is logged in fuzzy_url during startup/config init,
which is why we ignore it there.
The-Compiler wants a more beautiful test case since the old one was
pretty weird and took lots of explaining at pytest demos, so I made a
new one. This one is a bit nicer on the eye and - to say it with
The-Compiler's words - has no "weird pixelated globe with the
geocities-like background".
To compensate for the globe I've put in some trivia facts so that - if
you are one of the people that like to stare at test pages - you can
always learn something.
After pressing the button to open a window, we have to wait until it's loaded
before continuing, otherwise the test is flaky:
http://www.qutebrowser.org/testresults/osx/1295.html
We can't simply wait with "wait until about:blank is loaded" as that page is
already loaded earlier.
