Less hacky way to make XPASS yellow markup. Make sure collect reports still have a "when" attribute.
xfail changed to XFAIL in the test report, for consistency with other outcomes which are all CAPS
To keep existing tests which emit RemovedInPytest4Warnings running, decided
to go with a command line option because:
* Is harder to integrate an ini option with tests which already use an ini file
* It also marks tests which need to be removed/updated in 4.1, when
RemovedInPytest4Warning and related functionality are removed.
Fix#3737
Ref: https://github.com/pytest-dev/pytest/issues/4321#issuecomment-436951894
Hardens some of the not many tests affected by this:
1. `testing/test_session.py::test_rootdir_option_arg` displayed:
> root/test_rootdir_option_arg2/test_rootdir_option_arg.py
2. `test_cmdline_python_namespace_package` displayed "hello/" prefix for:
> hello/test_hello.py::test_hello
> hello/test_hello.py::test_other
This fixes running `pytest tests/test_foo.py::test_bar`, where `tests`
is a symlink to `project/app/tests`: previously
`project/app/conftest.py` would be ignored for fixtures then.
The problem was that _matchnodes would receive two items: [DoctestModule, Module]. It would then collect the first one, *cache it*, and fail to match against the name in the command line. Next, it would reuse the cached item (DoctestModule) instead of collecting the Module which would eventually find the "test" name on it.
Added the type of the node to the cache key to avoid this problem, although I'm not a big fan of caches that have different key types.
Fix#3843
Now each in-process pytest run saves a snapshot of important global Python
state and restores it after the test completes, including the list of loaded
modules & the Python path settings.
Previously only the loaded package data was getting restored, but that was
also reverting any loaded package changes done in the test triggering the
pytest runs, and not only those done by the pytest runs themselves.
Updated acceptance tests broken by this change, which were only passing before
by accident as they were making multiple pytest runs with later ones depending
on sys.path changes left behind by the initial one.
os.symlink might fail on Windows because users require a special policy
to create symlinks (argh).
This is not a problem on AppVeyor because it is logged in as an admin,
but would be surprising for Windows users running pytest's test
suite on their computer.