tests/test_clamav.py:58:89: E501 line too long (90 > 88 characters)
tests/test_containers.py:38:9: F841 local variable 'dummy' is assigned to but never used
tests/test_dummy.py:35:9: F841 local variable 'dummy' is assigned to but never used
tests/test_ftpparse.py:94:89: E501 line too long (96 > 88 characters)
tests/test_url.py:128:89: E501 line too long (130 > 88 characters)
tests/test_strformat.py:62:9: E741 ambiguous variable name 'l'
tests/test_strformat.py:136:9: E731 do not assign a lambda expression, use a def
tests/checker/ftpserver.py:94:9: E722 do not use bare 'except'
tests/checker/httpserver.py:55:39: E231 missing whitespace after ','
tests/checker/httpserver.py:224:9: E722 do not use bare 'except'
tests/checker/telnetserver.py:84:9: E722 do not use bare 'except'
tests/checker/__init__.py:71:89: E501 line too long (119 > 88 characters)
tests/checker/__init__.py:292:13: E741 ambiguous variable name 'l'
tests/checker/test_http_misc.py:30:1: W293 blank line contains whitespace
tests/checker/test_https.py:21:1: F401 'tests.need_network' imported but unused
tests/checker/test_news.py:35:1: E302 expected 2 blank lines, found 1
Except for tests that include non-unicode characters:
tests/test_po.py
tests/test_strformat.py
tests/test_url.py
tests/checker/test_error.py
tests/checker/test_news.py
Linkchecker's telnet://username:password@host:port URL verification logic is
- connect to host:port
- wait for 'login: ' to appear (with a 10 second timeout), send username
- wait for 'Password: ' to appear (with a 10 second timeout), send password
The test spawns a fake telnet server on localhost that never presented
the login/password prompts, forcing the 10 second timeout three times.
This commit makes the fake telnet server emit the expected prompts,
making the test pass in .2 seconds.
In cast we forget or somebody else wants to tackle this. After all, the
assertion error + traceback shows up at the end of the test run, and
it's not immediately clear which test is to blame for it!
I'm not entirely sure why the test is hanging, but this seems clear
enough:
- the test setup spawns a (non-daemon) background thread that runs
forever, or until it is told to quit by receiving a TCP packet on a
certain port
- the test teardown tries to tell the background thread to quit (which
doesn't work) and waits for that to happen
- as a result the entire test run hangs forever
This commit adds a timeout as an extra safety net so that the test run
will complete even if the clean shutdown procedure fails for some
reason.
