@nicoddemus

Would you mind helping me with some pytest related warnings and how to deal with them?

See this Travis build

Two types of warnings:

1. PytestUnknownMarkWarning
2. PytestCollectionWarning

In the tests conftest.py here

Things I've tried:

• I tried adding ignore::PytestUnknownMarkWarning to the generated setup.cfg to fix (1) and adding testpaths = testing to fix (2)

• I tried generating a pytest.ini using makeini with markers = <list of markers> to fix (1) and testpaths = testing to fix (2)

None of these strategies worked. Please advise. :)

Hi @BeyondEvil,

The "unknown marks warning" are because the marks are not being registered. Now how to fix this depends on each mark:

1. Is the mark for internal use, in the sense it is used only by pytest-seleniums own tests? In that case you should register the marks in your pytest.ini.

2. Is the mark public, in the sense it is a mark that users of the plugin will use on their own code? In that case, you should register the marks in a pytest_configure hook in your plugin.

Here are two examples: https://docs.pytest.org/en/latest/mark.html#registering-marks

About the collection warning, it is happening because pytest is collecting pytest_selenium/drivers/testingbot.py (because it matches test*.py) and attempting to collect TestingBot (matching Test* for classes), but refuses to do it because it defines an __init__ method.

You can fix this by either renaming the class to something else that doesn't match Test*, changing python_classes in your pytest.ini setting so it no longer matches TestingBot, or even configure pytest to only look into the testing directory by default by adding testpaths=testing to your pytest.ini.

Let me know if you still encounter any problems. 👍

@nicoddemus

Sorry, I should've been more clear. They're used by pytest-seleniums own tests. The "public" ones are registered properly.

As for fixing that. Like you saw in the link we're generating a setup.cfg and I even tried generating a pytest.ini with the registering of marks and testpaths keys. But to no avail. Are you saying I can add a "real" pytest.ini file that tox (pytest) will pick up? Where would I add it in the folder hierarchy?

Thanks 🙏

Are you saying I can add a "real" pytest.ini file that tox (pytest) will pick up? Where would I add it in the folder hierarchy?

Yes, a pytest.ini in the root of the directory is fine.

Alternatively, you can add a [pytest] section to your tox.ini and pytest will also pick it up (pytest itself does this).

Adding

[pytest]
testpaths = testing
markers =
    edge
    safari
    chrome
    skip_selenium
    nondestructive
    phantomjs

to tox.ini, solved the marker warnings, but not the collection warning. Any idea why?

Also, the tox command that is run is: commands = pytest -n auto -v -r a {posargs}
which generates on my machine 8 workers.

Which gives me 8 warnings for the same issue:

== warnings summary ==
pytest_selenium/drivers/testingbot.py:16
pytest_selenium/drivers/testingbot.py:16
pytest_selenium/drivers/testingbot.py:16
pytest_selenium/drivers/testingbot.py:16
pytest_selenium/drivers/testingbot.py:16
pytest_selenium/drivers/testingbot.py:16
pytest_selenium/drivers/testingbot.py:16
pytest_selenium/drivers/testingbot.py:16
  /Users/jimbrannlund/dev/pytest-dev/pytest-selenium/pytest_selenium/drivers/testingbot.py:16: PytestCollectionWarning: cannot collect test class 'TestingBot' because it has a __init__ constructor
    class TestingBot(Provider):

-- Docs: https://docs.pytest.org/en/latest/warnings.html
== 26 failed, 71 passed, 1 skipped, 1 xfailed, 8 warnings in 11.27 seconds ==

Known issue?
@nicoddemus

Strange, testpaths should have worked: https://docs.pytest.org/en/latest/reference.html#confval-testpaths

As a test, can you please change your tox.ini to execute pytest -n auto -v -r a testing instead? 🤔

Strange, testpaths should have worked: https://docs.pytest.org/en/latest/reference.html#confval-testpaths

Yeah, even pytest itself uses that exact key and value. 🤷‍♂

As a test, can you please change your tox.ini to execute pytest -n auto -v -r a testing instead? 🤔

Tried it, no difference. 🤔

Strange, I can reproduce this in my machine, seems like a bug... could you file an issue please?

Meanwhile you can ignore this specific warning by using filterwarnings in your [pytest] setting.

Working on docs @davehunt

I think the test that failed was a fluke (the build timed out).

But it will be re-run when I add the docs. )