Stop creating qute_test! #1637

Merged
merged 12 commits into from Jul 20, 2016

Conversation

Projects
None yet
5 participants
@rcorre
Collaborator

rcorre commented Jul 10, 2016

~/.config/qute_test and ~/.local/share/qute_test kept showing up on disk.
They really mess with my tab completion, but took me a while to figure out it was these unittests, as I just kept assuming I forgot to delete them. πŸ˜„.

Also, the fixture to prevent creation of ~/.cache/qute_test wasn't working because usefixtures doesn't work on fixture, as a past version of you pointed out.


This change is Reviewable

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Jul 10, 2016

Collaborator

Whoops! Seems like this makes TestCreatingDir.test_basedir[runtime] fail on Windows though, could you take a look?

Collaborator

The-Compiler commented Jul 10, 2016

Whoops! Seems like this makes TestCreatingDir.test_basedir[runtime] fail on Windows though, could you take a look?

@codecov-io

This comment has been minimized.

Show comment
Hide comment
@codecov-io

codecov-io Jul 11, 2016

Current coverage is 81.40%

Merging #1637 into master will increase coverage by 0.01%

@@             master      #1637   diff @@
==========================================
  Files           110        110          
  Lines         16163      16163          
  Methods           0          0          
  Messages          0          0          
  Branches       2518       2518          
==========================================
+ Hits          13156      13158     +2   
+ Misses         2511       2510     -1   
+ Partials        496        495     -1   

Powered by Codecov. Last updated by 6f65973...7d36847

codecov-io commented Jul 11, 2016

Current coverage is 81.40%

Merging #1637 into master will increase coverage by 0.01%

@@             master      #1637   diff @@
==========================================
  Files           110        110          
  Lines         16163      16163          
  Methods           0          0          
  Messages          0          0          
  Branches       2518       2518          
==========================================
+ Hits          13156      13158     +2   
+ Misses         2511       2510     -1   
+ Partials        496        495     -1   

Powered by Codecov. Last updated by 6f65973...7d36847

tests/unit/utils/test_standarddir.py
"""Test that system-wide path isn't used on linux if path not exist."""
+ args = types.SimpleNamespace(basedir=str(tmpdir))
+ standarddir.init(args)

This comment has been minimized.

@The-Compiler

The-Compiler Jul 11, 2016

Collaborator

With the qtwebengine branch I also added a fake_args fixture so you can do fake_args.basedir = str(tmpdir) (similar to config_stub) and it also gets registered in objreg accordingly - would you mind rebasing and switching to that?

@The-Compiler

The-Compiler Jul 11, 2016

Collaborator

With the qtwebengine branch I also added a fake_args fixture so you can do fake_args.basedir = str(tmpdir) (similar to config_stub) and it also gets registered in objreg accordingly - would you mind rebasing and switching to that?

tests/unit/utils/test_standarddir.py
"""Test that system-wide path is not used on non-Linux OS."""
+ args = types.SimpleNamespace(basedir=str(tmpdir))
+ standarddir.init(args)

This comment has been minimized.

@The-Compiler

The-Compiler Jul 11, 2016

Collaborator

ditto

@The-Compiler

The-Compiler Jul 11, 2016

Collaborator

ditto

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Jul 12, 2016

Collaborator

Not sure why pylint is still failing as I did rerun it against the newest master... anyways, looks good locally.

edit: Err, no, it doesn't:

C:343, 0: Line too long (80/79) (line-too-long)

I'll fix it before merging though.

Also seems a new random Qt warning message popped up:

____________________ TestSessionDelete.test_deletion_error _____________________
tests/unit/misc/test_sessions.py:838: Failure: Qt messages with level WARNING or above emitted
----------------------------- Captured Qt messages -----------------------------
../gui/text/qfontengine_ft.cpp:QFontEngineFT::Glyph* QFontEngineFT::loadGlyph(QFontEngineFT::QGlyphSet*, uint, QFixed, QFontEngine::GlyphFormat, bool) const:881:
    QtWarningMsg: load glyph failed err=6 face=0x70855a0, glyph=260
py-3974.log.0

Time to whitelist another one, I guess.

Collaborator

The-Compiler commented Jul 12, 2016

Not sure why pylint is still failing as I did rerun it against the newest master... anyways, looks good locally.

edit: Err, no, it doesn't:

C:343, 0: Line too long (80/79) (line-too-long)

I'll fix it before merging though.

Also seems a new random Qt warning message popped up:

____________________ TestSessionDelete.test_deletion_error _____________________
tests/unit/misc/test_sessions.py:838: Failure: Qt messages with level WARNING or above emitted
----------------------------- Captured Qt messages -----------------------------
../gui/text/qfontengine_ft.cpp:QFontEngineFT::Glyph* QFontEngineFT::loadGlyph(QFontEngineFT::QGlyphSet*, uint, QFixed, QFontEngine::GlyphFormat, bool) const:881:
    QtWarningMsg: load glyph failed err=6 face=0x70855a0, glyph=260
py-3974.log.0

Time to whitelist another one, I guess.

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Jul 12, 2016

Collaborator

hmm - after running all tests with this, I still see a ~/.config/qute_test being created.

Collaborator

The-Compiler commented Jul 12, 2016

hmm - after running all tests with this, I still see a ~/.config/qute_test being created.

The-Compiler added a commit that referenced this pull request Jul 12, 2016

@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Jul 12, 2016

Collaborator

Argh, I broke it while trying to fix the windows build. Should be good now, as long as the windows build passes.

Collaborator

rcorre commented Jul 12, 2016

Argh, I broke it while trying to fix the windows build. Should be good now, as long as the windows build passes.

@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Jul 12, 2016

Collaborator

Excuse the re-pushes, having trouble running pylint:

Traceback (most recent call last):
  File "/home/rcorre/projects/contrib/qutebrowser/.tox/pylint/bin/pylint", line 11, in <module>
    sys.exit(run_pylint())
  File "/home/rcorre/projects/contrib/qutebrowser/.tox/pylint/lib/python3.5/site-packages/pylint/__init__.py", line 23, in run_pylint
    Run(sys.argv[1:])
  File "/home/rcorre/projects/contrib/qutebrowser/.tox/pylint/lib/python3.5/site-packages/pylint/lint.py", line 1280, in __init__
    linter.load_plugin_modules(plugins)
  File "/home/rcorre/projects/contrib/qutebrowser/.tox/pylint/lib/python3.5/site-packages/pylint/lint.py", line 487, in load_plugin_modules
    module = modutils.load_module_from_name(modname)
  File "/home/rcorre/projects/contrib/qutebrowser/.tox/pylint/lib/python3.5/site-packages/astroid/modutils.py", line 186, in load_module_from_name
    return load_module_from_modpath(dotted_name.split('.'), path, use_sys)
  File "/home/rcorre/projects/contrib/qutebrowser/.tox/pylint/lib/python3.5/site-packages/astroid/modutils.py", line 228, in load_module_from_modpath
    mp_file, mp_filename, mp_desc = imp.find_module(part, path)
  File "/home/rcorre/projects/contrib/qutebrowser/.tox/pylint/lib/python3.5/imp.py", line 296, in find_module
    raise ImportError(_ERR_MSG.format(name), name=name)
ImportError: No module named 'bad_builtin'

I've run tox -r -e mkvenv, any idea what this is?

Collaborator

rcorre commented Jul 12, 2016

Excuse the re-pushes, having trouble running pylint:

Traceback (most recent call last):
  File "/home/rcorre/projects/contrib/qutebrowser/.tox/pylint/bin/pylint", line 11, in <module>
    sys.exit(run_pylint())
  File "/home/rcorre/projects/contrib/qutebrowser/.tox/pylint/lib/python3.5/site-packages/pylint/__init__.py", line 23, in run_pylint
    Run(sys.argv[1:])
  File "/home/rcorre/projects/contrib/qutebrowser/.tox/pylint/lib/python3.5/site-packages/pylint/lint.py", line 1280, in __init__
    linter.load_plugin_modules(plugins)
  File "/home/rcorre/projects/contrib/qutebrowser/.tox/pylint/lib/python3.5/site-packages/pylint/lint.py", line 487, in load_plugin_modules
    module = modutils.load_module_from_name(modname)
  File "/home/rcorre/projects/contrib/qutebrowser/.tox/pylint/lib/python3.5/site-packages/astroid/modutils.py", line 186, in load_module_from_name
    return load_module_from_modpath(dotted_name.split('.'), path, use_sys)
  File "/home/rcorre/projects/contrib/qutebrowser/.tox/pylint/lib/python3.5/site-packages/astroid/modutils.py", line 228, in load_module_from_modpath
    mp_file, mp_filename, mp_desc = imp.find_module(part, path)
  File "/home/rcorre/projects/contrib/qutebrowser/.tox/pylint/lib/python3.5/imp.py", line 296, in find_module
    raise ImportError(_ERR_MSG.format(name), name=name)
ImportError: No module named 'bad_builtin'

I've run tox -r -e mkvenv, any idea what this is?

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Jul 12, 2016

Collaborator

tox -r -e mkvenv only recreates .venv which is useful for testing stuff or running the newest qutebrowser from git.

pylint runs with a separate environment (.tox/pylint) - to run it you'd use tox -e pylint, so to recreate it (and thus install the newest pylint version) you'll need to do tox -e pylint -r. Unfortunately tox doesn't understand requirements.txt files, so it doesn't know when it needs to rebuild an enviroment because the dependency versions changed...

Collaborator

The-Compiler commented Jul 12, 2016

tox -r -e mkvenv only recreates .venv which is useful for testing stuff or running the newest qutebrowser from git.

pylint runs with a separate environment (.tox/pylint) - to run it you'd use tox -e pylint, so to recreate it (and thus install the newest pylint version) you'll need to do tox -e pylint -r. Unfortunately tox doesn't understand requirements.txt files, so it doesn't know when it needs to rebuild an enviroment because the dependency versions changed...

@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Jul 12, 2016

Collaborator

Ah, right. I remember you telling me this before :)

Collaborator

rcorre commented Jul 12, 2016

Ah, right. I remember you telling me this before :)

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Jul 12, 2016

Collaborator

Hmm, looks like the test from #1639 is flaky - no idea why yet... Will take a look.

Collaborator

The-Compiler commented Jul 12, 2016

Hmm, looks like the test from #1639 is flaky - no idea why yet... Will take a look.

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Jul 12, 2016

Collaborator

Turns out it just broke on Windows because backslashes are used for paths but also for escaping in the commandline πŸ˜‰ Fixed it, rerunning the build now.

Collaborator

The-Compiler commented Jul 12, 2016

Turns out it just broke on Windows because backslashes are used for paths but also for escaping in the commandline πŸ˜‰ Fixed it, rerunning the build now.

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Jul 12, 2016

Collaborator

Hmm, I still see a ~/.config/qute_test though...

Collaborator

The-Compiler commented Jul 12, 2016

Hmm, I still see a ~/.config/qute_test though...

@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Jul 13, 2016

Collaborator

@The-Compiler really? After just running this test or the whole test suite? Maybe something else creates it...

Collaborator

rcorre commented Jul 13, 2016

@The-Compiler really? After just running this test or the whole test suite? Maybe something else creates it...

@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Jul 13, 2016

Collaborator

Yup, you're right. Another test is guilty. I'll try to track it down

Collaborator

rcorre commented Jul 13, 2016

Yup, you're right. Another test is guilty. I'll try to track it down

@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Jul 13, 2016

Collaborator

Alright, I think I've got the culprits:

-----
config:  tests/unit/browser/test_adblock.py tests/unit/config/test_configtypes.py tests/unit/config/test_configtypes_hypothesis.py tests/unit/config/test_config.py
-----
data:  tests/unit/browser/webkit/test_cookies.py tests/unit/browser/webkit/test_qt_javascript.py tests/unit/browser/test_tab.py

Assuming I did this right, my script ran them individually and checked for qute_test after each run.

Collaborator

rcorre commented Jul 13, 2016

Alright, I think I've got the culprits:

-----
config:  tests/unit/browser/test_adblock.py tests/unit/config/test_configtypes.py tests/unit/config/test_configtypes_hypothesis.py tests/unit/config/test_config.py
-----
data:  tests/unit/browser/webkit/test_cookies.py tests/unit/browser/webkit/test_qt_javascript.py tests/unit/browser/test_tab.py

Assuming I did this right, my script ran them individually and checked for qute_test after each run.

@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Jul 13, 2016

Collaborator

For reference (mostly in case I need this again): here's the script

Collaborator

rcorre commented Jul 13, 2016

For reference (mostly in case I need this again): here's the script

@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Jul 15, 2016

Collaborator

@The-Compiler I think I got em all this time. 80b3528 was a bit more complicated than the others. Let me know what you think of that solution. Is XDG respected on windows?

Collaborator

rcorre commented Jul 15, 2016

@The-Compiler I think I got em all this time. 80b3528 was a bit more complicated than the others. Let me know what you think of that solution. Is XDG respected on windows?

@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Jul 15, 2016

Collaborator

Apparently Appveyor is not in a condition to answer that question for me >.<

Collaborator

rcorre commented Jul 15, 2016

Apparently Appveyor is not in a condition to answer that question for me >.<

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Jul 15, 2016

Collaborator

Ah, seems like we're running into QTBUG-54258 there. Windows won't respect XDG, but it's the best we can do, and that bug is fixed in Qt 5.6.2/5.7.1 already.

Not sure yet what's going on on AppVeyor, but it's happened for pytest-qt as well. Will investigate...

Collaborator

The-Compiler commented Jul 15, 2016

Ah, seems like we're running into QTBUG-54258 there. Windows won't respect XDG, but it's the best we can do, and that bug is fixed in Qt 5.6.2/5.7.1 already.

Not sure yet what's going on on AppVeyor, but it's happened for pytest-qt as well. Will investigate...

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Jul 15, 2016

Collaborator

In the meantime, do you know why this now fails in some configurations on Travis?

____________________ TestGetAllObjects.test_get_all_objects ____________________
self = <test_debug.TestGetAllObjects object at 0x7fd5582dc6d8>
stubs = <module 'helpers.stubs' from '/home/user/qutebrowser.git/tests/helpers/stubs.py'>
monkeypatch = <_pytest.monkeypatch.monkeypatch object at 0x7fd5582dc550>
    def test_get_all_objects(self, stubs, monkeypatch):
        # pylint: disable=unused-variable
        widgets = [self.Object('Widget 1'), self.Object('Widget 2')]
        app = stubs.FakeQApplication(all_widgets=widgets)
        monkeypatch.setattr(debug, 'QApplication', app)

        root = QObject()
        o1 = self.Object('Object 1', root)
        o2 = self.Object('Object 2', o1)  # flake8: disable=F841
        o3 = self.Object('Object 3', root)  # flake8: disable=F841

        expected = textwrap.dedent("""
                Qt widgets - 2 objects:
                    <Widget 1>
                    <Widget 2>

                Qt objects - 3 objects:
                    <Object 1>
                        <Object 2>
                    <Object 3>

                global object registry - 0 objects:
            """).rstrip('\n')

>       assert debug.get_all_objects(start_obj=root) == expected
E       assert "\nQt widgets...-max-items'))" == '\nQt widgets ... - 0 objects:'
E         Skipping 145 identical leading characters in diff, use -v to show
E         - egistry - 1 objects:
E         ?           ^
E         + egistry - 0 objects:
E         ?           ^
E         -     command-history: qutebrowser.misc.lineparser.LimitLineParser(binary=False, configdir=None, fname='cmd-history', limit=('completion', 'cmd-history-max-items'))
tests/unit/utils/test_debug.py:266: AssertionError

It seems to me like some test leaves a lineparser in the global object registry now?

Collaborator

The-Compiler commented Jul 15, 2016

In the meantime, do you know why this now fails in some configurations on Travis?

____________________ TestGetAllObjects.test_get_all_objects ____________________
self = <test_debug.TestGetAllObjects object at 0x7fd5582dc6d8>
stubs = <module 'helpers.stubs' from '/home/user/qutebrowser.git/tests/helpers/stubs.py'>
monkeypatch = <_pytest.monkeypatch.monkeypatch object at 0x7fd5582dc550>
    def test_get_all_objects(self, stubs, monkeypatch):
        # pylint: disable=unused-variable
        widgets = [self.Object('Widget 1'), self.Object('Widget 2')]
        app = stubs.FakeQApplication(all_widgets=widgets)
        monkeypatch.setattr(debug, 'QApplication', app)

        root = QObject()
        o1 = self.Object('Object 1', root)
        o2 = self.Object('Object 2', o1)  # flake8: disable=F841
        o3 = self.Object('Object 3', root)  # flake8: disable=F841

        expected = textwrap.dedent("""
                Qt widgets - 2 objects:
                    <Widget 1>
                    <Widget 2>

                Qt objects - 3 objects:
                    <Object 1>
                        <Object 2>
                    <Object 3>

                global object registry - 0 objects:
            """).rstrip('\n')

>       assert debug.get_all_objects(start_obj=root) == expected
E       assert "\nQt widgets...-max-items'))" == '\nQt widgets ... - 0 objects:'
E         Skipping 145 identical leading characters in diff, use -v to show
E         - egistry - 1 objects:
E         ?           ^
E         + egistry - 0 objects:
E         ?           ^
E         -     command-history: qutebrowser.misc.lineparser.LimitLineParser(binary=False, configdir=None, fname='cmd-history', limit=('completion', 'cmd-history-max-items'))
tests/unit/utils/test_debug.py:266: AssertionError

It seems to me like some test leaves a lineparser in the global object registry now?

@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Jul 15, 2016

Collaborator

Weird -- no idea. It doesn't happen when running test_debug in isolation. I'm running the full suite locally now.

Collaborator

rcorre commented Jul 15, 2016

Weird -- no idea. It doesn't happen when running test_debug in isolation. I'm running the full suite locally now.

@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Jul 15, 2016

Collaborator

Well, I haven't found where the lineparser comes from, but I did find that
running test_debug immediately following test_tab fails:

.tox/py35/bin/python scripts/dev/run_pytest.py -- tests/unit/browser/test_tab.py tests/unit/utils/test_debug.py
tests/unit/browser/test_tab.py ....
tests/unit/utils/test_debug.py ..............x.x....................F

___________________________________________________________________________________________ TestGetAllObjects.test_get_all_objects_qapp ___________________________________________________________________________________________

self = <test_debug.TestGetAllObjects object at 0x7efdb40b3eb8>

    @pytest.mark.usefixtures('qapp')
    def test_get_all_objects_qapp(self):
>       objects = debug.get_all_objects()

tests/unit/utils/test_debug.py:270:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
qutebrowser/utils/debug.py:284: in get_all_objects
    widget_lines = _get_widgets()
qutebrowser/utils/debug.py:270: in _get_widgets
    widgets.sort(key=repr)
qutebrowser/browser/browsertab.py:595: in __repr__
    url = utils.elide(self.url().toDisplayString(QUrl.EncodeUnicode),
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <[NotImplementedError("") raised in repr()] AbstractTab object at 0x7efdb7dda288>

    def url(self):
>       raise NotImplementedError
E       NotImplementedError

qutebrowser/browser/browsertab.py:541: NotImplementedError
Collaborator

rcorre commented Jul 15, 2016

Well, I haven't found where the lineparser comes from, but I did find that
running test_debug immediately following test_tab fails:

.tox/py35/bin/python scripts/dev/run_pytest.py -- tests/unit/browser/test_tab.py tests/unit/utils/test_debug.py
tests/unit/browser/test_tab.py ....
tests/unit/utils/test_debug.py ..............x.x....................F

___________________________________________________________________________________________ TestGetAllObjects.test_get_all_objects_qapp ___________________________________________________________________________________________

self = <test_debug.TestGetAllObjects object at 0x7efdb40b3eb8>

    @pytest.mark.usefixtures('qapp')
    def test_get_all_objects_qapp(self):
>       objects = debug.get_all_objects()

tests/unit/utils/test_debug.py:270:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
qutebrowser/utils/debug.py:284: in get_all_objects
    widget_lines = _get_widgets()
qutebrowser/utils/debug.py:270: in _get_widgets
    widgets.sort(key=repr)
qutebrowser/browser/browsertab.py:595: in __repr__
    url = utils.elide(self.url().toDisplayString(QUrl.EncodeUnicode),
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <[NotImplementedError("") raised in repr()] AbstractTab object at 0x7efdb7dda288>

    def url(self):
>       raise NotImplementedError
E       NotImplementedError

qutebrowser/browser/browsertab.py:541: NotImplementedError
@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Jul 15, 2016

Collaborator

Ah, I see. There's a timing delay with qtbot disposing of widgets. A tab gets left behind after running test_tab and can screw up test_debug if that test is run immediately following. If I add time.sleep(0.1) after this line it works. I'm guessing its the same deal with LimitLineParser.

Collaborator

rcorre commented Jul 15, 2016

Ah, I see. There's a timing delay with qtbot disposing of widgets. A tab gets left behind after running test_tab and can screw up test_debug if that test is run immediately following. If I add time.sleep(0.1) after this line it works. I'm guessing its the same deal with LimitLineParser.

@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Jul 15, 2016

Collaborator

test_config is the one actually responsible for the error you reported.

Collaborator

rcorre commented Jul 15, 2016

test_config is the one actually responsible for the error you reported.

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Jul 15, 2016

Collaborator

Weird... not sure why your changes trigger this then!

I opened #1652 now, and I'll probably get rid of objreg (#640) after Europython, I'm so fed up with it. Better to have normal Python attributes when globals are really needed, so we can at least use monkeypatch.

Collaborator

The-Compiler commented Jul 15, 2016

Weird... not sure why your changes trigger this then!

I opened #1652 now, and I'll probably get rid of objreg (#640) after Europython, I'm so fed up with it. Better to have normal Python attributes when globals are really needed, so we can at least use monkeypatch.

rcorre added some commits Jul 9, 2016

Don't create real config/data dirs from tests.
Running the tests would create ~/.config/qute_test and
~/.local/share/qute_test on the user's machine. The test_standardir
module needed a bit more mocking to prevent it from cluttering the
user's machine.

Two tests that created the data dir were fixed by passing basedir in
args, and one test that created the config dir was fixed by patching
os.makedirs to a noop.
Prevent tests from creating cachedir tag.
Running test_standarddir would pollute the user's home with
`~/.cache/qute_test`.

The `no_cachedir_tag` fixture was supposed to prevent this, but was not
working because [usefixtures does not work on fixtures]
(pytest-dev/pytest#1014).

This fixes the fixture to actually prevent cachedir creation, but
applies it to tests individually (or by class) rather than with autouse
because the cachedir tests cannot pass if it is working.
Fix standarddir test on Windows.
Was broken by 48a2cad while trying to prevent creation of qute_test in
non-temp locations.

rcorre added some commits Jul 12, 2016

Completely prevent tests from creating cachedir.
Attempting to fix the test on windows caused it to create the cachedir
again. The call to init(None) was unnecessary.
Prevent test_adblock from creating real config dir.
Don't create ~/.config/qute_test by mocking out standdarddir.config for
all tests in this module.

This adds config_tmpdir to fixtures.py and moves temp_datadir from
test_adblock to fixtures.py as it will be needed more broadly.
Prevent creation of user dirs on several tests.
Use the config_tempdir and data_tempdir fixtures for several tests that
were creation ~/.config/qute_test or ~/.local/share/qute_test.
Don't write to user datadir in test_qt_javascript.
This was more complicated than the other data/config/cachedir test
fixes, as QtWebEngine was accessing the datadir directly (and bypassing
standdarddir.data).

This means the tmpdir_data stub is not enough, we need to set
XDG_DATA_HOME to redirect access.
@lahwaacz

This comment has been minimized.

Show comment
Hide comment
@lahwaacz

lahwaacz Jul 16, 2016

Collaborator

Also, the tools used in the virtual environment create their own directories, e.g. ~/.pylint.d/. Can't they be confined to the virtualenv?

Collaborator

lahwaacz commented Jul 16, 2016

Also, the tools used in the virtual environment create their own directories, e.g. ~/.pylint.d/. Can't they be confined to the virtualenv?

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Jul 16, 2016

Collaborator

@lahwaacz I took a quick look at the pylint manpage, seems like we could set PYLINTHOME accordingly in tox.ini. Did you spot anything else?

Collaborator

The-Compiler commented Jul 16, 2016

@lahwaacz I took a quick look at the pylint manpage, seems like we could set PYLINTHOME accordingly in tox.ini. Did you spot anything else?

@lahwaacz

This comment has been minimized.

Show comment
Hide comment
@lahwaacz

lahwaacz Jul 16, 2016

Collaborator

Well, tox itself creates ~/.tox/distshare/qutebrowser-0.7.0.zip, even though it is exactly the same file as .tox/dist/qutebrowser-0.7.0.zip in the dev root directory.

Running tox -e py35 seems to start its own dbus daemon with dbus-launch --autolaunch - the daemon is running while the tests are running and ~/.dbus/ is left behind. I have a dbus running as systemd service, so maybe $DBUS_SESSION_BUS_ADDRESS could be reused?

Other than that, I didn't spot anything.

Collaborator

lahwaacz commented Jul 16, 2016

Well, tox itself creates ~/.tox/distshare/qutebrowser-0.7.0.zip, even though it is exactly the same file as .tox/dist/qutebrowser-0.7.0.zip in the dev root directory.

Running tox -e py35 seems to start its own dbus daemon with dbus-launch --autolaunch - the daemon is running while the tests are running and ~/.dbus/ is left behind. I have a dbus running as systemd service, so maybe $DBUS_SESSION_BUS_ADDRESS could be reused?

Other than that, I didn't spot anything.

@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Jul 16, 2016

Collaborator

Oh, weird. pytestmark = pytest.mark.usefixtures('config_tmpdir') at the top of test_config causes it to leave around a LineParser that interferes with test_debug.

Collaborator

rcorre commented Jul 16, 2016

Oh, weird. pytestmark = pytest.mark.usefixtures('config_tmpdir') at the top of test_config causes it to leave around a LineParser that interferes with test_debug.

rcorre added some commits Jul 16, 2016

Prevent lingering object from test_config.
Using the config_tmdpir fixture across all tests in this module caused
a lingering LineParser to make test_debug fail.
I still don't know why, but scoping the config_tmpdir fixture to only
the test class that was creating ~/.config/qute_test fixes the issue,
and still prevents creation of a user tempdir.
Prevent test_tab from creating user data dir.
This is another case (like test_qt_javascript) that needs redirection
of XDG_DATA_HOME to prevent Qt from creating ~/.share/local/qute_test.
Use monkeypatch.setenv instead of os.putenv.
This ensures the environment is modified only for the test using the
fixture rather than for the whole test run.
Limit config_tmpdir use in test_configtypes.
Only use the fixture in the test class that tries to access the config
dir (TestFileAndUserStyleSheet) rather than the whole test.
@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Jul 19, 2016

Collaborator

@The-Compiler I think this is good to go now. The two failures seem setup related

Collaborator

rcorre commented Jul 19, 2016

@The-Compiler I think this is good to go now. The two failures seem setup related

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Jul 20, 2016

Collaborator

I've hit rebuild, but it might still take me a few days until I get to merging it πŸ˜‰

Collaborator

The-Compiler commented Jul 20, 2016

I've hit rebuild, but it might still take me a few days until I get to merging it πŸ˜‰

@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Jul 20, 2016

Collaborator

Sounds good, I may look into @lahwaacz's comment about ~/.pylint.d. I think I tried setting PYLINTHOME manually and it worked, so I just need to figure out how that fits into tox.ini

Collaborator

rcorre commented Jul 20, 2016

Sounds good, I may look into @lahwaacz's comment about ~/.pylint.d. I think I tried setting PYLINTHOME manually and it worked, so I just need to figure out how that fits into tox.ini

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Jul 20, 2016

Collaborator

I had some time right now - already cleaned pylint and tox.

Collaborator

The-Compiler commented Jul 20, 2016

I had some time right now - already cleaned pylint and tox.

@The-Compiler The-Compiler merged commit 48dbf50 into qutebrowser:master Jul 20, 2016

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

The-Compiler added a commit that referenced this pull request Jul 20, 2016

The-Compiler added a commit that referenced this pull request Jul 20, 2016

tox: Set distshare = {toxworkdir}
This is kind uf unorthodox and the "distshare" setting seems to be
deprecated, but we don't get a ~/.tox this way.

See #1637

@rcorre rcorre deleted the rcorre:cut_test_clutter branch Jul 20, 2016

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Jul 20, 2016

Collaborator

Merged, thanks!

Some commits on top of it:

  • pylint: Set persistent=n - c4fb43d
  • tox: Set distshare = {toxworkdir} - 5f2dc53
  • Rename shadowed tmpdir variable - a1c4e6e
Collaborator

The-Compiler commented Jul 20, 2016

Merged, thanks!

Some commits on top of it:

  • pylint: Set persistent=n - c4fb43d
  • tox: Set distshare = {toxworkdir} - 5f2dc53
  • Rename shadowed tmpdir variable - a1c4e6e
@lahwaacz

This comment has been minimized.

Show comment
Hide comment
@lahwaacz

lahwaacz Aug 28, 2016

Collaborator

Now it seems that ~/.qute_test/ and ~/.QtWebEngineProcess/ are left behind after the webengine part of the tests. Unfortunately the whole test suite does not pass for me due to #1819, can somebody confirm that these directories stay after running tox -e py35?

Also there is still the problem with ~/.dbus/, which is created about 3 minutes before the previous two dirs, so it seems unrelated to webengine. Can anything be done about this or is it a lost cause?

Collaborator

lahwaacz commented Aug 28, 2016

Now it seems that ~/.qute_test/ and ~/.QtWebEngineProcess/ are left behind after the webengine part of the tests. Unfortunately the whole test suite does not pass for me due to #1819, can somebody confirm that these directories stay after running tox -e py35?

Also there is still the problem with ~/.dbus/, which is created about 3 minutes before the previous two dirs, so it seems unrelated to webengine. Can anything be done about this or is it a lost cause?

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Aug 28, 2016

Collaborator

@lahwaacz I think at least the ~/.qute_test one was fixed in Qt, not sure about ~/.QtWebEngineProcess.

Collaborator

The-Compiler commented Aug 28, 2016

@lahwaacz I think at least the ~/.qute_test one was fixed in Qt, not sure about ~/.QtWebEngineProcess.

@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Aug 28, 2016

Collaborator

@The-Compiler IIRC one of the .qute_test instances was created internally by QtWebKit andt I had to fix it by setting and environment variable, so it makes sense that it might come back with the WebEngine tests

Collaborator

rcorre commented Aug 28, 2016

@The-Compiler IIRC one of the .qute_test instances was created internally by QtWebKit andt I had to fix it by setting and environment variable, so it makes sense that it might come back with the WebEngine tests

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Aug 29, 2016

Collaborator

I don't think they were ever created with QtWebKit - I'm only aware of QTBUG-54258.

Though I'd expect that to be prevented via the redirect_xdg_data fixture @rcorre added - which tests are you running exactly, @lahwaacz?

Collaborator

The-Compiler commented Aug 29, 2016

I don't think they were ever created with QtWebKit - I'm only aware of QTBUG-54258.

Though I'd expect that to be prevented via the redirect_xdg_data fixture @rcorre added - which tests are you running exactly, @lahwaacz?

@lahwaacz

This comment has been minimized.

Show comment
Hide comment
@lahwaacz

lahwaacz Aug 29, 2016

Collaborator

I was running tox -e py35, but not all of it (#1819). I narrowed it down to tests/unit/browser/test_tab.py::test_tab[QWebEngineView], which is also the test that fails for me in xvfb, but ~/.qute_test and ~/.QtWebEngineProcess are created even with --no-xvfb.

Collaborator

lahwaacz commented Aug 29, 2016

I was running tox -e py35, but not all of it (#1819). I narrowed it down to tests/unit/browser/test_tab.py::test_tab[QWebEngineView], which is also the test that fails for me in xvfb, but ~/.qute_test and ~/.QtWebEngineProcess are created even with --no-xvfb.

@rcorre

This comment has been minimized.

Show comment
Hide comment
@rcorre

rcorre Aug 29, 2016

Collaborator

Whoops, I misread. ~/.qute_test was never created -- it was ~/.local/share/qute_test and ~/.config/qute_test. Do you have $XDG_DATA_HOME or $XDG_CONFIG_HOME set?

Collaborator

rcorre commented Aug 29, 2016

Whoops, I misread. ~/.qute_test was never created -- it was ~/.local/share/qute_test and ~/.config/qute_test. Do you have $XDG_DATA_HOME or $XDG_CONFIG_HOME set?

@lahwaacz

This comment has been minimized.

Show comment
Hide comment
@lahwaacz

lahwaacz Aug 29, 2016

Collaborator

Yes, they point to the usual paths ~/.local/share and ~/.config respectively.

Collaborator

lahwaacz commented Aug 29, 2016

Yes, they point to the usual paths ~/.local/share and ~/.config respectively.

The-Compiler added a commit that referenced this pull request Sep 12, 2016

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Sep 12, 2016

Collaborator

Seems like QtWebEngine happily writes stuff to the homedir without respecting any XDG_* vars...

I also redirected that in e6680c3 and opened QTBUG-55946 about it too.

Collaborator

The-Compiler commented Sep 12, 2016

Seems like QtWebEngine happily writes stuff to the homedir without respecting any XDG_* vars...

I also redirected that in e6680c3 and opened QTBUG-55946 about it too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment