If you are wondering where the data of this site comes from, please visit GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Reverb Chu reverbc an apprentice wizard

reverbc/pytest-concurrent 50

concurrently execute test cases with multi-thread, multi-process and gevent

reverbc/pylint-pytest 32

A Pylint plugin to suppress pytest-related false positives.

reverbc/vscode-pytest 2

Pytest IntelliSense Extension for VS Code

reverbc/checkin 0

automatically launch/close app when switching to different wireless network

reverbc/Chromodynamics 0

Sublime Text & Atom color scheme.

reverbc/easyargs 0

A python module to make handling command line arguments easy

reverbc/faker 0

Faker is a Python package that generates fake data for you.

reverbc/jokekappa 0

A library for delivering one-line programming jokes

reverbc/jsonresume-theme-elegant 0

Elegant theme for jsonresume

reverbc/maildiff 0

Gets a notification when forwarded mail never arrive its destination.

issue commentreverbc/pylint-pytest

Fixtures depended by other fixtures reported as unused imports

When you have a fixture that is local to the test module, not global for the whole test session. Also, you may override the global fixtures with some values specific to your module (by redefining fixtures with the same name).

@webknjaz sorry for the confusion - that question was actually addressed to @Jaakkonen. I'm interested in the pattern they're using (manually import fixtures from vs. automatically imported by


comment created time in 25 days

issue commentreverbc/pylint-pytest

Fixtures depended by other fixtures reported as unused imports

AFAIK, pytest will only register the fixtures that are available in the locals() of the current module, or from locals() of the magic If we don't explicitly import the my_fixture in this module it will not load it.

FWIW I think that what you're trying to do is an antipattern and you should probably move the fixture imports or even their declarations to instead. I don't think that pylint-pytest should encourage this usage pattern.

Yes I do agree with that. In general we should register the fixtures to, and we do avoid the plugin from complaining unused imported fixtures in at

I'm wondering if there's a specific use case that you don't want to import the fixtures into


comment created time in 25 days

issue commentreverbc/pylint-pytest

Handle pytest failure

Out of interest, @reverbc did that reproduce the error on your end?

#22 should fix this issue when the raise/sys.exit(1) occurs in an unrelated module


comment created time in 25 days

issue commentreverbc/pylint-pytest

Not working W0613: Unused argument 'virtual_site' (unused-argument)

This sounds reasonable. If you're not going to use the fixture's return value, just apply it via @pytest.mark.usefixtures('virtual_site').

Another pytest linting plugin (but for flake8) even enforces this approach and I think this would be the right thing to do:

I do like this pattern for explicitly using a fixture without accessing its return/yield value. However, due to pytest limitation that @pytest.mark.usefixtures has no effect in fixture functions, we'll need to have separate handling for test methods and fixture functions. That's an implementation detail tho.

I think we can make a new convention rule to suggest this change since it's still a valid usage.


comment created time in 25 days


Pull request review commentreverbc/pylint-pytest

🐛 Ignore collection failures in non-tests

 def visit_module(self, node):                  FixtureChecker._pytest_fixtures = fixture_collector.fixtures -                if (ret != pytest.ExitCode.OK or fixture_collector.errors) and is_test_module:-                    self.add_message('cannot-enumerate-pytest-fixtures', node=node)+                legitimate_failure_paths = set(+                    collection_report.nodeid+                    for collection_report in fixture_collector.errors+                    if any(+                        fnmatch.fnmatch(+                            Path(collection_report.nodeid).name, pattern,+                        )+                        for pattern in FILE_NAME_PATTERNS+                    )+                )+                if (ret != pytest.ExitCode.OK or legitimate_failure_paths) and is_test_module:+                    self.add_message(+                        'cannot-enumerate-pytest-fixtures',+                        args=' '.join(legitimate_failure_paths | {node.file}),

I found that there's a potential duplication from this line: legitimate_failure_paths can contain relative paths, but the node.file is in absolute path. In my env it's throwing out pytest warning with duplicated paths:

sandbox/ F6401: pylint-pytest plugin cannot enumerate and collect pytest fixtures. Please run `pytest --fixtures --collect-only sandbox/ /Users/reverbc/Workspace/pylint-pytest/sandbox/` and resolve any potential syntax error or package dependency issues (cannot-enumerate-pytest-fixtures)

Where the sandbox/ and /Users/reverbc/Workspace/pylint-pytest/sandbox/ are pointing to the same file.

Can you help to unify the path strings, maybe with str(Path(...).absolute()) for both collection_report.nodeid and node.file?


comment created time in 25 days


issue commentreverbc/pylint-pytest

[BUG]Why does adding a module produce F6401

Pytest should only collect fixtures from the test modules, and instead of collecting fixtures from all modules, Pylint-Pytest should filter out the source code when PyLint checks.

I believe we have other use cases that pytest should care about non-test modules.

Similar to #2 use case, test author can use separate modules (let's call them helper modules) to organize their fixtures/helpers if they have a large and complex test framework. In that case, if there's a coding error in one of the helper modules and causing the pytest failed to enumerate the fixtures, pylint-pytest will not be able to suppress the FP. That was the main intention when I introduced this new warning, and unfortunately the fixes in #22 will not be able to prevent that from happening since it'll ignore the collection errors from helper modules.

I'm now more inclined to temporary remove this cannot-enumerate-pytest-fixtures check if it cannot correctly identify which modules actually contain pytest fixtures until we have a better solution to detect that.


comment created time in a month