This started from fixing the test, where `"xdist_strict True"` was used
as a single argument, although you typically would see `["xdist_strict",
"True"]`.
Improves the error message to mention the option that caused the error.
pytest has several instances where plugins set their own attributes on
objects they receive in hooks, like nodes and config. Since plugins are
detached from these object's definition by design, this causes a problem
for type checking because these attributes are not defined and mypy
complains.
Fix this by giving these objects a "store" which can be used by plugins
in a type-safe manner.
Currently this mechanism is private. We can consider exposing it at a
later point.
The pytest-konira plugin has not seen an update since 2011, moreover
the "project description" on PyPI points to a dubious website that
does not actually correspond to the project and instead redirects to
advertising content.
It should only return `True` when something is to be ignored, not
`False` otherwise typically.
This caused e.g. bad interaction with the cacheprovider (before
https://github.com/pytest-dev/pytest/pull/6448).
Passing in a tuple crashes in `_prepareconfig`:
def test_invoke_with_tuple(self):
> pytest.main(("-h",))
src/_pytest/config/__init__.py:82: in main
config = _prepareconfig(args, plugins)
src/_pytest/config/__init__.py:229: in _prepareconfig
return pluginmanager.hook.pytest_cmdline_parse(
…
src/_pytest/helpconfig.py:98: in pytest_cmdline_parse
config = outcome.get_result() # type: Config
src/_pytest/config/__init__.py:808: in pytest_cmdline_parse
self.parse(args)
src/_pytest/config/__init__.py:1017: in parse
self._preparse(args, addopts=addopts)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
def _preparse(self, args: List[str], addopts: bool = True) -> None:
…
if addopts:
ini_addopts = self.getini("addopts")
if ini_addopts:
> args[:] = self._validate_args(ini_addopts, "via addopts config") + args
E TypeError: can only concatenate list (not "tuple") to list
addopts = True
args = ('-h',)
env_addopts = ''
ini_addopts = ['-rfEX', …]
src/_pytest/config/__init__.py:956: TypeError: can only concatenate list (not "tuple") to list
Might be worth handling (converting it to a list for example), but it
was documented to be a list to begin with when removing support for
strings (a7e401656).
Remove `_tmp_path_factory` and `_tmpdirhandler` from the config object.
- `_tmpdirhandler` has been deprecated since 2.8.0 (0f52856f9), when
`tmpdir_factory` has been added.
- `_tmp_path_factory` should have probably never been added there in the
first place, but maybe just used the same pattern (16e2737da).
This better reflects the inheritance / smartness with regard to raw or
encoded.
- FDCaptureBinary
- FDCapture
- SysCaptureBinary
- SysCapture
- TeeSysCapture
Mypy currently is unable to handle assigning attributes on function:
https://github.com/python/mypy/issues/2087.
pytest uses this for the outcome exceptions -- `pytest.fail.Exception`,
`pytest.exit.Exception` etc, and this is the canonical name by which they
are referred.
Initially we started working around this with type: ignores, and later
by switching e.g. `pytest.fail.Exception` with the direct exception
`Failed`. But this causes a lot of churn and is not as nice. And I also
found that some code relies on it, in skipping.py:
def pytest_configure(config):
if config.option.runxfail:
# yay a hack
import pytest
old = pytest.xfail
config._cleanup.append(lambda: setattr(pytest, "xfail", old))
def nop(*args, **kwargs):
pass
nop.Exception = xfail.Exception
setattr(pytest, "xfail", nop)
...
So it seems better to support it. Use a hack to make it work. The rest
of the commit rolls back all of the workarounds we added up to now.
`pytest.raises.Exception` also exists, but it's not used much so I kept
it as-is for now.
Hopefully in the future mypy supports this and this ugliness can be
removed.
Allows for filtering of PytestCacheWarning.
Using `_issue_warning_captured` is not necessary here, and was probably
only used because the cacheprovider misses warnings during
`pytest_sessionfinish`, which is also fixed here.
I think the usage of `_issue_warning_captured` can be removed/reduced
further, but also that this is good enough for now.
Ref: https://github.com/pytest-dev/pytest/issues/6681.
* Turn ReprTraceback into attrs class
* Use attr.asdict with serialize_repr_{crash,traceback}
* Turn ReprFileLocation into attrs class, convert py.path.local
* Use code highlighting if pygments is installed
* Use colorama constants instead of bare ascii codes
Could not find the exact equivalent of 'hl-reset' code using colorama
constants though.
* Refactor ASCII color handling into a fixture
* Revert back to using explicit color codes
* In Python 3.5 skip rest of tests that require ordered markup in colored output
Use suggestion in review and use a subplugin so hooks will only be active
if we enable faulthandler ourselves.
Fix#6575
Co-authored-by: Daniel Hahler <git@thequod.de>
ExitCode is used in several internal modules and hooks and so with type
annotations added, needs to be imported a lot.
_pytest.main, being the entry point, generally sits at the top of the
import tree.
So, it's not great to have ExitCode defined in _pytest.main, because it
will cause a lot of import cycles once type annotations are added (in
fact there is already one, which this change removes).
Move it to _pytest.config instead.
_pytest.main still imports ExitCode, so importing from there still
works, although external users should really be importing from `pytest`.
The convention is "assert result is expected". Pytest's error diffs now
reflect this. "-" means that sth. expected is missing in the result and
"+" means that there are unexpected extras in the result.
Fixes: #3333
Fix mypy errors:
src/_pytest/runner.py:36: error: "addoption" of "OptionGroup" does not return a value [func-returns-value]
src/_pytest/helpconfig.py:64: error: "addoption" of "OptionGroup" does not return a value [func-returns-value]
src/_pytest/terminal.py:67: error: "_addoption" of "OptionGroup" does not return a value [func-returns-value]
src/_pytest/terminal.py:75: error: "_addoption" of "OptionGroup" does not return a value [func-returns-value]
Fixes collection error with Python 3.5.3 (Travis):
testing/test_parseopt.py:2: in <module>
import distutils.spawn
.tox/py35-coverage/lib/python3.5/distutils/__init__.py:4: in <module>
import imp
.tox/py35-coverage/lib/python3.5/imp.py:33: in <module>
PendingDeprecationWarning, stacklevel=2)
E PendingDeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
Build log: https://travis-ci.org/blueyed/pytest/builds/648305304
This started by looking at how to get the current test item in general,
and then I noticed that it is not necessary for the capture plugin to
track it manually in the first place.
Previously this would be turned via `py.path.local("")` into the current
working directory.
This appears to be what `fspath = fn and py.path.local(fn) or None`
tries to avoid in `getfslineno`'s `TypeError` handling already, if
`Code` would raise it.
Everything was using `_pytest.compat.getfslineno` basically, which
wrapped `_pytest._code.source.getfslineno`.
This moves the extra code from there into it directly, and uses the
latter everywhere.
This helps to eventually remove the one in compat eventually, and also
causes less cyclic imports.
* Explicitly state on the PR template that we can squash commits
This way we don't need to ask every time, and users who for some reason
would not like us to squash their commits can explicitly state so.
Plugins specified with ``-p`` are now loaded after internal plugins, which
results in their hooks being called *before* the internal ones.
This makes the ``-p`` behavior consistent with ``PYTEST_PLUGINS``.
* fix/adjust test_disable_plugin_autoload
* adjust test_plugin_loading_order
`Generator` was removed in 7eb28f9eb, and this pleases mypy to correctly
complain that `FunctionMixin` has no `config` (within
`_prunetraceback`).
* typing: _prunetraceback
* minor: imports, typing
Reverts https://github.com/pytest-dev/pytest/pull/6610.
The tested `getfslineno` is `src/_pytest/_code/source.py` actually,
exported via `src/_pytest/_code/__init__.py`.
I've confused it with the one in `src/_pytest/compat.py` apparently.
It should be in `test_code` when testing `_pytest._code.getfslineno`,
not to be confused with `_pytest._code.source.getfslineno`.
Adds an extra assert (via https://github.com/pytest-dev/pytest/pull/6590).
This often might be causing for jobs to take longer than 10 minutes,
which is a timeout Codecov uses to wait for successful CI.
Also it is good in general to have CI finish faster, of course.
From the description it seemed to me as if just prefixing your methods with ``test_`` was enough, but you also need to prefix your class with ``Test``. Of course, in the reference material this is clearly stated, but I think it makes sense to mention it here as well, since you also mention the part about the methods' prefix.
While it might not help with the following, it certainly might happen as
well.
```
+ curl -S -L --connect-timeout 5 --retry 6 -s https://codecov.io/bash -o codecov-upload.sh
curl: (16) Error in the HTTP2 framing layer
```
- refactor _get_main_color/build_summary_stats_line
- factor out property _is_last_item; test_summary_stats: tr._is_last_item
- _write_progress_information_filling_space: remove color arg
- use setter for stats, handling main color
- _get_main_color: skip cache for last item
- Handle random order in test for py35.
Mypy complains about this once the function is typed:
src/_pytest/main.py:85: error: "_addoption" of "OptionGroup" does not return a value
src/_pytest/main.py:133: error: "addoption" of "OptionGroup" does not return a value
Previously, this cache was used with 3 different and mutually exclusive
key-type -> value-type combinations. Mypy can't properly type this. It's
also quite confusing.
Split to 3 different dicts instead.
Previously, _initialparts was a list whose first item was a
`py.path.local` and the rest were `str`s. This is not something that
mypy is capable of modeling. The type `List[Union[str, py.path.local]]`
is too broad and would require asserts for every access.
Instead, make each item a `Tuple[py.path.local, List[str]]`. This way
the structure is clear and the types are accurate.
To make sure any users who might have been accessing this (private)
field will not break silently, change the name to _initial_parts.
Make EncodedFile, used for captured output streams, method .write return
the number of characters written. Add test for captured stderr write.
Fixes#6557.
Co-Authored-By: Bruno Oliveira <nicoddemus@gmail.com>
Without restoring the cwd, successive tests might fail to parse the
config (via `_pytest.config._prepareconfig()`, for when `--lsof` is
used).
And it is good practice to restore the cwd in any case anyway.
These are more "dirty" than the previous batch (that's why they were
left out). The trouble is that `compile` can return either a code object
or an AST depending on a flag, so we need to add an overload to make the
common case Union free. But it's still worthwhile.
GitHub actions already should deploy.
This is a stop gap while we figure out why coverage dropped
when removing Travis builds in #6470
(cherry picked from commit d1d7e5d41b)
Somehow in Python 3.5 on Windows this test fails with:
File "c:\hostedtoolcache\windows\python\3.5.4\x64\Lib\multiprocessing\connection.py", line 302, in _recv_bytes
overlapped=True)
OSError: [WinError 6] The handle is invalid
This only happens in this platform and Python version, decided to use
a dummy traceback as originally done in #6412.
(cherry picked from commit b9c136b809)
This allows for e.g. Jedi to infer types (it checks the name).
It was only used to support Python 3.5.0/3.5.1, where this is is not
available in the `typing` module.
Ref: https://github.com/davidhalter/jedi/issues/1472
Uses `TYPE_CHECKING = False` in `_pytest.outcomes` to avoid having to
work around circular import.
Somehow in Python 3.5 on Windows this test fails with:
File "c:\hostedtoolcache\windows\python\3.5.4\x64\Lib\multiprocessing\connection.py", line 302, in _recv_bytes
overlapped=True)
OSError: [WinError 6] The handle is invalid
This only happens in this platform and Python version, decided to use
a dummy traceback as originally done in #6412.
This is different from what pre-commit (in "linting") runs in that it
uses stubs from (test) dependencies.
It would make sense to run this on CI additionally (since there is no
"pre-commit --skip mypy", and a separate config is not worth it).
But currently it triggers a false positive though anyway
(https://github.com/erikrose/more-itertools/pull/374).
This overwrites the `codecov.yml` file in the root of the repository with
`codecov-upstream.yml` file (which contains the code-cov token)´, so PRs
and branches on the repository can upload coverage.
Suggestion from here:
https://github.com/pytest-dev/pytest/pull/6421#issuecomment-571934112
Security concerns: the token might be misused, but only to upload bogus coverage
to `codecov.io`, so the team believe this is harmless. If we decide to fallback
from this decision , we just need to revoke the token.
Related to #6369
Both references were referencing links from Python because of our intersphinx
mapping in `conf.py`:
intersphinx_mapping = {"python": ("https://docs.python.org/3", None)}
Because Python's docs explicitly define both references, Sphinx fallbacks to
them instead of generating implicit references as was expected.
Fix#6397
Tracebacks coming from remote processes crated by the multiprocess module
will contain "RemoteTracebacks" which don't have a 'reprcrash' attribute
Fix#5971
I've updated the text and incorporated the topics from #5275, so this
can now be part of the official docs, and #5275 can be closed/unpinned.
Closes#5275
This fixes some type: ignores due to typeshed update.
Newer mypy seem to ignore unannotated functions better, so add a few
minor annotations so that existing correct type:ignores make sense.
* Rearrange section about context manager to be in order
* Link to `pytest.warns` and `recwarn` since a reader going top to bottom won't have seen about those yet.
* Used only context manager form in the example; the call form is somewhat obsolete
and is mentioned in the reference docs already.
* Reuse the 'myfunction' from first example on the second one
Co-Authored-By: Hugo van Kemenade <hugovk@users.noreply.github.com>
Co-Authored-By: Hugo van Kemenade <hugovk@users.noreply.github.com>
This includes our current full matrix (windows, linux and macos), for evaluting
purposes.
We should disconsider failures when evaluating PRs.
TODO:
- deploy
- coverage
- github release notes
Even with the above missing, I still believe it would be nice to merge
this and have GitHub actions working in parallel so we can evaluate performance
and usability from now on.
The order of invocations 'python -m pytest' and 'pytest' are different in the header and the explanation. Me being lazy reading about the behaviour of 'former' looked up quickly the title and rushed to implementation to discover it actually works the other way - as stated in the documentation. So I propose to switch the order in the title to achieve consistent ordering and not confusing somebody like me again! :)
While using pytest-repeat, I noticed the previous implementation is slow
for a large number of duplicate test ids. To optimize, this commit
reduces the amount of data copied and avoids using `in` with List
(unhashable type, and therefore is very slow for many elements).
As far as the output is concerned, they are both identical so it doesn't
make sense to have both.
setup, teardown, and collect failures are already reported as "errors", "E".
Now `tox -e docs` will also include the draft changelog for the
next version (locally only).
`CHANGELOG.rst` now only points to the changelog on READTHEDOCS so
sphinx diretives can be used.
Followup to https://github.com/pytest-dev/pytest/pull/6272
Sets `PY_COLORS=0` in the environment by default, which is used by pylib.
Via https://github.com/blueyed/pytest/pull/58
(initially cherry picked from commit f153ad33d10)
This configures the default role for interpreted text (single
backticks), avoiding the need to check for / enforce double backticks.
Fixes also one instance in the existing changelog:
- Detect `pytest_` prefixed hooks using the internal plugin manager since
``pluggy`` is deprecating the ``implprefix`` argument to ``PluginManager``.
(`#3487 <https://github.com/pytest-dev/pytest/issues/3487>`_)
This feature was added in commit
007a77c2ba, but was never used in pytest
itself. A GitHub code search doesn't find any users either (only pytest
repo copies). It seems safe to clean up.
`tox -vv` is too verbose, and was only used as a hack to get the output
of durations.
As for information in logs `-v` could be used maybe still, but I've
decided to revert it for now.
This reverts commit 56cec5fa79.
Source was previously iterable because it implements `__getitem__()`,
which is apparently a thing from before `__iter__()` was introduced.
To reduce mypy's and my own confusion, implement `__iter__()` directly.
The previous test was better in that it used fakes to test all of the
real code paths. The problem with that is that it makes it impossible to
simplify the code with `isinstance` checks. So let's just simulate the
issue directly with a monkeypatch.
Add some Python 3.8 type: ignores; all are already fixed in the next
mypy release, so can be removed once we upgrade.
Also move some flake8 ignores which seem to have changed places.
It currently fails with a TypeError, and was not updated since 2013 -
therefore it can be assumed that it is not important to support it.
```
____________________ ERROR collecting test_nested_marks.py _____________________
…/Vcs/pluggy/src/pluggy/hooks.py:286: in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
…/Vcs/pluggy/src/pluggy/manager.py:93: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
…/Vcs/pluggy/src/pluggy/manager.py:337: in traced_hookexec
return outcome.get_result()
…/Vcs/pluggy/src/pluggy/manager.py:335: in <lambda>
outcome = _Result.from_call(lambda: oldcall(hook, hook_impls, kwargs))
…/Vcs/pluggy/src/pluggy/manager.py:87: in <lambda>
firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
…/Vcs/pytest/src/_pytest/python.py:235: in pytest_pycollect_makeitem
res = list(collector._genfunctions(name, obj))
…/Vcs/pytest/src/_pytest/python.py:404: in _genfunctions
self.ihook.pytest_generate_tests.call_extra(methods, dict(metafunc=metafunc))
…/Vcs/pluggy/src/pluggy/hooks.py:324: in call_extra
return self(**kwargs)
…/Vcs/pluggy/src/pluggy/hooks.py:286: in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
…/Vcs/pluggy/src/pluggy/manager.py:93: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
…/Vcs/pluggy/src/pluggy/manager.py:337: in traced_hookexec
return outcome.get_result()
…/Vcs/pluggy/src/pluggy/manager.py:335: in <lambda>
outcome = _Result.from_call(lambda: oldcall(hook, hook_impls, kwargs))
…/Vcs/pluggy/src/pluggy/manager.py:87: in <lambda>
firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
…/Vcs/pytest/src/_pytest/python.py:130: in pytest_generate_tests
metafunc.parametrize(*marker.args, **marker.kwargs)
…/Vcs/pytest/src/_pytest/python.py:965: in parametrize
function_definition=self.definition,
…/Vcs/pytest/src/_pytest/mark/structures.py:111: in _for_parametrize
if len(param.values) != len(argnames):
E TypeError: object of type 'MarkDecorator' has no len()
!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!
```
This comes via hypothesis:
```
% COLUMNS=80 p testing/python/metafunc.py::TestMetafunc::test_idval_hypothesis -vv --tb=short
============================= test session starts ==============================
platform linux -- Python 3.7.4, pytest-3.1.4.dev721+g3367bf03b.d20191112, py-1.8.1.dev11+g34f716fe, pluggy-0.13.1.dev8+ga5130ac.d20191103 -- …/Vcs/pytest/.venv/bin/python
cachedir: .pytest_cache
hypothesis profile 'default' -> database=DirectoryBasedExampleDatabase('…/Vcs/pytest/.hypothesis/examples')
rootdir: …/Vcs/pytest, inifile: tox.ini
plugins: forked-1.1.3, hypothesis-4.44.1, cov-2.8.1, coverage-pytest-plugin-0.1, enhancements-0.0.5.dev1-gf361636-dirty, xdist-1.30.0
collected 1 item
testing/python/metafunc.py::TestMetafunc::test_idval_hypothesis FAILED [100%]
=================================== FAILURES ===================================
______________________ TestMetafunc.test_idval_hypothesis ______________________
.venv/lib/python3.7/site-packages/hypothesis/core.py:588: in evaluate_test_data
result = self.execute(data)
.venv/lib/python3.7/site-packages/hypothesis/core.py:553: in execute
result = self.test_runner(data, run)
.venv/lib/python3.7/site-packages/hypothesis/executors.py:56: in default_new_style_executor
return function(data)
.venv/lib/python3.7/site-packages/hypothesis/core.py:536: in run
args, kwargs = data.draw(self.search_strategy)
.venv/lib/python3.7/site-packages/hypothesis/internal/conjecture/data.py:857: in draw
return strategy.do_draw(self)
.venv/lib/python3.7/site-packages/hypothesis/core.py:223: in do_draw
return self.mapped_strategy.do_draw(data)
.venv/lib/python3.7/site-packages/hypothesis/searchstrategy/collections.py:60: in do_draw
return tuple(data.draw(e) for e in self.element_strategies)
.venv/lib/python3.7/site-packages/hypothesis/searchstrategy/collections.py:60: in <genexpr>
return tuple(data.draw(e) for e in self.element_strategies)
.venv/lib/python3.7/site-packages/hypothesis/internal/conjecture/data.py:852: in draw
return strategy.do_draw(self)
.venv/lib/python3.7/site-packages/hypothesis/searchstrategy/strategies.py:570: in do_draw
result = self.pack(data.draw(self.mapped_strategy))
.venv/lib/python3.7/site-packages/hypothesis/internal/conjecture/data.py:852: in draw
return strategy.do_draw(self)
.venv/lib/python3.7/site-packages/hypothesis/searchstrategy/lazy.py:156: in do_draw
return data.draw(self.wrapped_strategy)
.venv/lib/python3.7/site-packages/hypothesis/internal/conjecture/data.py:852: in draw
return strategy.do_draw(self)
.venv/lib/python3.7/site-packages/hypothesis/searchstrategy/strategies.py:570: in do_draw
result = self.pack(data.draw(self.mapped_strategy))
.venv/lib/python3.7/site-packages/hypothesis/internal/conjecture/data.py:852: in draw
return strategy.do_draw(self)
.venv/lib/python3.7/site-packages/hypothesis/searchstrategy/collections.py:60: in do_draw
return tuple(data.draw(e) for e in self.element_strategies)
.venv/lib/python3.7/site-packages/hypothesis/searchstrategy/collections.py:60: in <genexpr>
return tuple(data.draw(e) for e in self.element_strategies)
.venv/lib/python3.7/site-packages/hypothesis/internal/conjecture/data.py:852: in draw
return strategy.do_draw(self)
.venv/lib/python3.7/site-packages/hypothesis/searchstrategy/strategies.py:508: in do_draw
return data.draw(self.element_strategies[i], label=self.branch_labels[i])
.venv/lib/python3.7/site-packages/hypothesis/internal/conjecture/data.py:852: in draw
return strategy.do_draw(self)
.venv/lib/python3.7/site-packages/hypothesis/searchstrategy/lazy.py:156: in do_draw
return data.draw(self.wrapped_strategy)
.venv/lib/python3.7/site-packages/hypothesis/internal/conjecture/data.py:852: in draw
return strategy.do_draw(self)
.venv/lib/python3.7/site-packages/hypothesis/searchstrategy/strategies.py:570: in do_draw
result = self.pack(data.draw(self.mapped_strategy))
.venv/lib/python3.7/site-packages/hypothesis/internal/conjecture/data.py:852: in draw
return strategy.do_draw(self)
.venv/lib/python3.7/site-packages/hypothesis/searchstrategy/lazy.py:156: in do_draw
return data.draw(self.wrapped_strategy)
.venv/lib/python3.7/site-packages/hypothesis/internal/conjecture/data.py:852: in draw
return strategy.do_draw(self)
.venv/lib/python3.7/site-packages/hypothesis/searchstrategy/collections.py:120: in do_draw
result.append(data.draw(self.element_strategy))
.venv/lib/python3.7/site-packages/hypothesis/internal/conjecture/data.py:852: in draw
return strategy.do_draw(self)
.venv/lib/python3.7/site-packages/hypothesis/searchstrategy/numbers.py:62: in do_draw
return d.integer_range(data, self.start, self.end)
.venv/lib/python3.7/site-packages/hypothesis/internal/conjecture/utils.py:105: in integer_range
probe = data.draw_bits(bits)
.venv/lib/python3.7/site-packages/hypothesis/internal/conjecture/data.py:974: in draw_bits
self.__check_capacity(n_bytes)
.venv/lib/python3.7/site-packages/hypothesis/internal/conjecture/data.py:1019: in __check_capacity
self.mark_overrun()
.venv/lib/python3.7/site-packages/hypothesis/internal/conjecture/data.py:1036: in mark_overrun
self.conclude_test(Status.OVERRUN)
.venv/lib/python3.7/site-packages/hypothesis/internal/conjecture/data.py:1027: in conclude_test
raise StopTest(self.testcounter)
E hypothesis.errors.StopTest: 0
During handling of the above exception, another exception occurred:
testing/python/metafunc.py:195: in test_idval_hypothesis
@hypothesis.settings(
.venv/lib/python3.7/site-packages/nose/__init__.py:1: in <module>
from nose.core import collector, main, run, run_exit, runmodule
.venv/lib/python3.7/site-packages/nose/core.py:12: in <module>
from nose.loader import defaultTestLoader
.venv/lib/python3.7/site-packages/nose/loader.py:21: in <module>
from nose.importer import Importer, add_path, remove_path
.venv/lib/python3.7/site-packages/nose/importer.py:12: in <module>
from imp import find_module, load_module, acquire_model1, release_model1
/usr/lib/python3.7/imp.py:33: in <module>
DeprecationWarning, stacklevel=2)
E DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
---------------------------------- Hypothesis ----------------------------------
You can add @seed(198901559535749756451579900660745168041) to this test or run pytest with --hypothesis-seed=198901559535749756451579900660745168041 to reproduce this failure.
=============================== warnings summary ===============================
testing/python/metafunc.py::TestMetafunc::test_idval_hypothesis
…/Vcs/pytest/.venv/lib/python3.7/site-packages/unittest2/compatibility.py:143: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
class ChainMap(collections.MutableMapping):
-- Docs: https://docs.pytest.org/en/latest/warnings.html
=========================== short test summary info ============================
FAILED testing/python/metafunc.py::TestMetafunc::test_idval_hypothesis - Depr...
```
This is a useful utility to abstract the caching property idiom.
It is in compat.py since eventually it will be replaced by
functools.cached_property.
Fixes#6131.
It is a little too obscure IMO, but the reason I want to drop it is that
type checking has no hope of understanding such dynamic constructs.
The warning argument wasn't used.
This is already covered by attrs.
Also, the custom implementation returns False when the types don't
match, but it's better to return `NotImplemented`. attrs does this.
This fixes/removes the previous hack of re-trying with minimum width,
which fails short when it splits strings.
This inherits from `pprint.PrettyPrinter` to override `_format` in a
minimal way to always dispatch, regardless of the given width.
Code ref: 5c0c325453/Lib/pprint.py (L170-L178)
Harden one test where it is tested.
All tests testing this:
testing/acceptance_test.py:184(TestGeneralUsage::test_not_collectable_arguments)
testing/acceptance_test.py:373(TestGeneralUsage::test_direct_addressing_notfound)
testing/acceptance_test.py:403(TestGeneralUsage::test_issue134_report_error_when_collecting_member[test_fun.py::test_a])
testing/acceptance_test.py:420(TestGeneralUsage::test_report_all_failed_collections_initargs)
testing/test_config.py:1309(test_config_blocked_default_plugins[python])
(via https://github.com/blueyed/pytest/pull/88)
Works around:
_____ ERROR collecting testing/io/test_saferepr.py _____
src/_pytest/python.py:502: in _importtestmodule
mod = self.fspath.pyimport(ensuresyspath=importmode)
.venv38/lib/python3.8/site-packages/py/_path/local.py:701: in pyimport
__import__(modname)
<frozen importlib._bootstrap>:991: in _find_and_load
???
<frozen importlib._bootstrap>:975: in _find_and_load_unlocked
???
<frozen importlib._bootstrap>:671: in _load_unlocked
???
src/_pytest/assertion/rewrite.py:136: in exec_module
source_stat, co = _rewrite_test(fn, self.config)
src/_pytest/assertion/rewrite.py:288: in _rewrite_test
co = compile(tree, fn, "exec", dont_inherit=True)
E File "…/Vcs/pytest/testing/io/test_saferepr.py", line 45
E None()
E ^
E SyntaxError: 'NoneType' object is not callable; perhaps you missed a comma?
This causes INTERNALERRORs with pytest-django, which uses
`pytest.fail` (derived from `BaseException`) to prevent DB access, when
pytest then tries to e.g. display the `repr()` for a Django `QuerySet`
etc.
Ref: https://github.com/pytest-dev/pytest-django/pull/776
Follow-up to 946434c61 (#5924).
Before this patch the test would look like this:
{'env': {'sub...s wrapped'}}}} == {'env': {'sub...}}}, 'new': 1}
Omitting 1 identical items, use -vv to show
Right contains 1 more item:
{'new': 1}
Full diff:
{
'env': {'sub': {'long_a': 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa',
- 'sub1': {'long_a': 'substring '
+ 'sub1': {'long_a': 'substring that gets wrapped'}}},
? +++++++++++++++++ ++++
+ 'new': 1,
- 'that '
- 'gets '
- 'wrapped'}}},
}
indicate current outcome/status with color of percentage indicator
Fix type annotation, refactor _write_progress_information_filling_space
Keep code in _get_main_color as similar as possible to how it was before
Write test
Make black-compliant
Fix error in newly introduced test_collecterror
Make tests more readable by using constants and f-strings
Remove accidentally added monkeypatch
Make Python 3.5-compatible, add changelog entry
Add newline at the end of changelog file
Remove the `--fulltrace` arg from the `Option` fixture used in several
tests, but not checked for. Only use it with `test_keyboard_interrupt`.
(removes 8 tests, coverage not affected)
The function handles bytes input, however that is never used.
The function has two callers:
1)
```
if istext(left) and istext(right):
explanation = _diff_text(left, right, verbose
```
`istext` checks `isinstance(str)`.
2)
```
def _notin_text(term: str, text: str, verbose: int = 0) -> List[str]:
...
diff = _diff_text(correct_text, text, verbose
```
and `_notin_text` is called once:
```
if istext(left) and istext(right):
explanation = _notin_text(left, right, verbose
```
Failed for me due to different indent (?) - not reproducible:
> ???
E Failed: nomatch: 'E TypeError: write() argument must be str, not bytes'
…
E and: '> def mode(self):'
E and: 'E TypeError: write() argument must be str, not bytes'
…
E remains unmatched: 'E TypeError: write() argument must be str, not bytes'
This would prevent TOXENV=py37-pexpect-… from running on e.g. FreeBSD.
And even on Windows it is pytest's job of skipping the tests then. This
was probably still from when the pexpect env was only running
pexpect-based tests.
In order to make the LiteralOutputChecker lazy initialization more
amenable to type checking, I changed it to match the scheme already used
in this file to lazy-initialize PytestDoctestRunner.
Changelogs:
http://mypy-lang.blogspot.com/2019/09/mypy-730-released.htmlhttp://mypy-lang.blogspot.com/2019/10/mypy-0740-released.html
New errors:
src/_pytest/recwarn.py:77: error: Missing return statement
src/_pytest/recwarn.py:185: error: "bool" is invalid as return type for "__exit__" that always returns False
src/_pytest/recwarn.py:185: note: Use "typing_extensions.Literal[False]" as the return type or change it to "None"
src/_pytest/recwarn.py:185: note: If return type of "__exit__" implies that it may return True, the context manager may swallow exceptions
src/_pytest/recwarn.py:185: error: Return type "bool" of "__exit__" incompatible with return type "None" in supertype "catch_warnings"
src/_pytest/recwarn.py:230: error: "bool" is invalid as return type for "__exit__" that always returns False
src/_pytest/recwarn.py:230: note: Use "typing_extensions.Literal[False]" as the return type or change it to "None"
src/_pytest/recwarn.py:230: note: If return type of "__exit__" implies that it may return True, the context manager may swallow exceptions
src/_pytest/recwarn.py:230: error: Return type "bool" of "__exit__" incompatible with return type "None" in supertype "catch_warnings"
The errors are due to this new error:
https://mypy.readthedocs.io/en/latest/error_code_list.html#check-the-return-type-of-exit-exit-return
This is important when used with ``pytester``'s ``runpytest_inprocess``.
Since 07f20ccab `pytest testing/acceptance_test.py -k test_doctest_id`
would fail, since the second run would not consider the exception to be
an instance of `doctest.DocTestFailure` anymore, since the module was
re-imported, and use another failure message then in the short test
summary info (and in the report itself):
> FAILED test_doctest_id.txt::test_doctest_id.txt - doctest.DocTestFailure: <Do...
while it should be:
> FAILED test_doctest_id.txt::test_doctest_id.txt
This avoids mutating the original list to reflect on InvocationParams,
which is supposed to be an immutable snapshot of the state of pytest.main()
at the moment of invocation (see pytest-dev/pytest-xdist#478).
Massage text input for difflib when comparing pformat output of
different line lengths.
Also do not strip ndiff output on the left, which currently already
removes indenting for lines with no differences.
Before:
E AssertionError: assert ['version', '...version_info'] == ['version', '...version', ...]
E Right contains 3 more items, first extra item: ' '
E Full diff:
E - ['version', 'version_info', 'sys.version', 'sys.version_info']
E + ['version',
E + 'version_info',
E + 'sys.version',
E + 'sys.version_info',
E + ' ',
E + 'sys.version',
E + 'sys.version_info']
After:
E AssertionError: assert ['version', '...version_info'] == ['version', '...version', ...]
E Right contains 3 more items, first extra item: ' '
E Full diff:
E [
E 'version',
E 'version_info',
E 'sys.version',
E 'sys.version_info',
E + ' ',
E + 'sys.version',
E + 'sys.version_info',
E ]
The current idiom is to use:
assert re.match(pat, result.stdout.str())
Or
assert line in result.stdout.str()
But this does not really give good results when it fails.
Those new functions produce similar output to ther other match lines functions.
Map `BdbQuit` exception to `outcomes.Exit`.
This is necessary since we are not wrapping `pdb.set_trace` there, and
therefore our `do_quit` is not called.
2019-07-19 02:57:25 +02:00
213 changed files with 18292 additions and 11893 deletions
@@ -3,13 +3,20 @@ Thanks for submitting a PR, your contribution is really appreciated!
Here is a quick checklist that should be present in PRs.
- [ ] Target the `master` branch for bug fixes, documentation updates and trivial changes.
- [ ] Target the `features` branch for new features, improvements, and removals/deprecations.
- [ ] Include documentation when adding new features.
- [ ] Include new tests or update existing tests when applicable.
- [X] Allow maintainers to push and squash when merging my commits. Please uncheck this if you prefer to squash the commits yourself.
Unless your change is trivial or a small documentation fix (e.g., a typo or reword of a small section) please:
- [ ] Create a new changelog file in the `changelog` folder, with a name like `<ISSUE NUMBER>.<TYPE>.rst`. See [changelog/README.rst](https://github.com/pytest-dev/pytest/blob/master/changelog/README.rst) for details.
Write sentences in the **past or present tense**, examples:
* *Improved verbose diff output with sequences.*
* *Terminal summary statistics now use multiple colors.*
Also make sure to end the sentence with a `.`.
- [ ] Add yourself to `AUTHORS` in alphabetical order.
This directory contains "newsfragments" which are short files that contain a small **ReST**-formatted
text that will be added to the next ``CHANGELOG``.
The ``CHANGELOG`` will be read by users, so this description should be aimed to pytest users
The ``CHANGELOG`` will be read by **users**, so this description should be aimed to pytest users
instead of describing internal changes which are only relevant to the developers.
Make sure to use full sentences with correct case and punctuation, for example::
Make sure to use full sentences in the **past or present tense** and use punctuation, examples::
Fix issue with non-ascii messages from the ``warnings`` module.
Improved verbose diff output with sequences.
Terminal summary statistics now use multiple colors.
Each file should be named like ``<ISSUE>.<TYPE>.rst``, where
``<ISSUE>`` is an issue number, and ``<TYPE>`` is one of:
*``feature``: new user facing features, like new command-line options and new behavior.
*``improvement``: improvement of existing functionality, usually without requiring user intervention (for example, new fields being written in ``--junitxml``, improved colors in terminal, etc).
*``bugfix``: fixes a reported bug.
*``bugfix``: fixes a bug.
*``doc``: documentation improvement, like rewording an entire session or adding missing docs.
*``deprecation``: feature deprecation.
*``removal``: feature removal.
*``breaking``: a change which may break existing suites, such as feature removal or behavior change.
*``vendor``: changes in packages vendored in pytest.
*``trivial``: fixing a small typo or internal change that might be noteworthy.
@@ -29,6 +31,7 @@ changelog using that instead.
If you are not sure what issue type to use, don't hesitate to ask in your PR.
``towncrier`` preserves multiple paragraphs and formatting (code blocks, lists, and so on), but for entries
other than ``features`` it is usually better to stick to a single paragraph to keep it concise. You can install
``towncrier`` and then run ``towncrier --draft``
if you want to get a preview of how your change will look in the final release notes.
other than ``features`` it is usually better to stick to a single paragraph to keep it concise.
You can also run ``tox -e docs`` to build the documentation
with the draft changelog (``doc/en/_build/html/changelog.html``) if you want to get a preview of how your change will look in the final release notes.
pytest is actively evolving and is a project that has been decades in the making,
we keep learning about new and better structures to express different details about testing.
While we implement those modifications we try to ensure an easy transition and don't want to impose unnecessary churn on our users and community/plugin authors.
As of now, pytest considers multipe types of backward compatibility transitions:
a) trivial: APIs which trivially translate to the new mechanism,
and do not cause problematic changes.
We try to support those indefinitely while encouraging users to switch to newer/better mechanisms through documentation.
b) transitional: the old and new API don't conflict
and we can help users transition by using warnings, while supporting both for a prolonged time.
We will only start the removal of deprecated functionality in major releases (e.g. if we deprecate something in 3.0 we will start to remove it in 4.0), and keep it around for at least two minor releases (e.g. if we deprecate something in 3.9 and 4.0 is the next release, we start to remove it in 5.0, not in 4.0).
When the deprecation expires (e.g. 4.0 is released), we won't remove the deprecated functionality immediately, but will use the standard warning filters to turn them into **errors** by default. This approach makes it explicit that removal is imminent, and still gives you time to turn the deprecated feature into a warning instead of an error so it can be dealt with in your own time. In the next minor release (e.g. 4.1), the feature will be effectively removed.
c) true breakage: should only to be considered when normal transition is unreasonably unsustainable and would offset important development/features by years.
In addition, they should be limited to APIs where the number of actual users is very small (for example only impacting some plugins), and can be coordinated with the community in advance.
Examples for such upcoming changes:
* removal of ``pytest_runtest_protocol/nextitem`` - `#895`_
* rearranging of the node tree to include ``FunctionDefinition``
* rearranging of ``SetupState```#895`_
True breakages must be announced first in an issue containing:
* Detailed description of the change
* Rationale
* Expected impact on users and plugin authors (example in `#895`_)
After there's no hard *-1* on the issue it should be followed up by an initial proof-of-concept Pull Request.
This POC serves as both a coordination point to assess impact and potential inspriation to come up with a transitional solution after all.
After a reasonable amount of time the PR can be merged to base a new major release.
For the PR to mature from POC to acceptance, it must contain:
* Setup of deprecation errors/warnings that help users fix and port their code. If it is possible to introduce a deprecation period under the current series, before the true breakage, it should be introduced in a separate PR and be part of the current release stream.
* Detailed description of the rationale and examples on how to port code in ``doc/en/deprecations.rst``.
History
=========
Focus primary on smooth transition - stance (pre 6.0)
Keeping backwards compatibility has a very high priority in the pytest project. Although we have deprecated functionality over the years, most of it is still supported. All deprecations in pytest were done because simpler or more efficient ways of accomplishing the same tasks have emerged, making the old way of doing things unnecessary.
With the pytest 3.0 release we introduced a clear communication scheme for when we will actually remove the old busted joint and politely ask you to use the new hotness instead, while giving you enough time to adjust your tests or raise concerns if there are valid reasons to keep deprecated functionality around.
@@ -20,3 +75,6 @@ Deprecation Roadmap
Features currently deprecated and removed in previous releases can be found in :ref:`deprecations`.
We track future deprecation and removal of features using milestones and the `deprecation <https://github.com/pytest-dev/pytest/issues?q=label%3A%22type%3A+deprecation%22>`_ and `removal <https://github.com/pytest-dev/pytest/labels/type%3A%20removal>`_ labels on GitHub.
@@ -20,6 +20,51 @@ Below is a complete list of all pytest features which are considered deprecated.
:ref:`standard warning filters <warnings>`.
``--no-print-logs`` command-line option
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
..deprecated:: 5.4
Option ``--no-print-logs`` is deprecated and meant to be removed in a future release. If you use ``--no-print-logs``, please try out ``--show-capture`` and
provide feedback.
``--show-capture`` command-line option was added in ``pytest 3.5.0` and allows to specify how to
display captured output when tests fail: ``no``, ``stdout``, ``stderr``, ``log`` or ``all`` (the default).
Node Construction changed to ``Node.from_parent``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
..deprecated:: 5.4
The construction of nodes new should use the named constructor ``from_parent``.
This limitation in api surface intends to enable better/simpler refactoring of the collection tree.
``junit_family`` default value change to "xunit2"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
..deprecated:: 5.2
The default value of ``junit_family`` option will change to ``xunit2`` in pytest 6.0, given
that this is the version supported by default in modern tools that manipulate this type of file.
In order to smooth the transition, pytest will issue a warning in case the ``--junitxml`` option
is given in the command line but ``junit_family`` is not explicitly configured in ``pytest.ini``::
PytestDeprecationWarning: The 'junit_family' default value will change to 'xunit2' in pytest 6.0.
Add 'junit_family=legacy' to your pytest.ini file to silence this warning and make your suite compatible.
In order to silence this warning, users just need to configure the ``junit_family`` option explicitly:
..code-block::ini
[pytest]
junit_family=legacy
``funcargnames`` alias for ``fixturenames``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -40,15 +85,27 @@ Result log (``--result-log``)
..deprecated:: 4.0
The ``--result-log`` option produces a stream of test reports which can be
analysed at runtime. It uses a custom format which requires users to implement their own
parser, but the team believes using a line-based format that can be parsed using standard
tools would provide a suitable and better alternative.
analysed at runtime, but it uses a custom format which requires users to implement their own
parser.
The current plan is to provide an alternative in the pytest 5.0 series and remove the``--result-log``
option in pytest 6.0 after the new implementation proves satisfactory to all users and is deemed
stable.
The `pytest-reportlog <https://github.com/pytest-dev/pytest-reportlog>`__ plugin provides a``--report-log`` option, a more standard and extensible alternative, producing
one JSON object per-line, and should cover the same use cases. Please try it out and provide feedback.
The actual alternative is still being discussed in issue `#4488 <https://github.com/pytest-dev/pytest/issues/4488>`__.
The plan is remove the ``--result-log`` option in pytest 6.0 if ``pytest-reportlog`` proves satisfactory
to all users and is deemed stable. The ``pytest-reportlog`` plugin might even be merged into the core
at some point, depending on the plans for the plugins and number of users using it.
TerminalReporter.writer
~~~~~~~~~~~~~~~~~~~~~~~
..deprecated:: 5.4
The ``TerminalReporter.writer`` attribute has been deprecated and should no longer be used. This
was inadvertently exposed as part of the public API of that plugin and ties it too much
with ``py.io.TerminalWriter``.
Plugins that used ``TerminalReporter.writer`` directly should instead use ``TerminalReporter``
The first invocation with ``db == "DB1"`` passed while the second with ``db == "DB2"`` failed. Our ``db`` fixture function has instantiated each of the DB values during the setup phase while the ``pytest_generate_tests`` generated two according calls to the ``test_db_initialized`` during the collection phase.
@@ -398,6 +402,9 @@ The result of this test will be successful:
.. regendoc:wipe
Note, that each argument in `parametrize` list should be explicitly declared in corresponding
python test function or via `indirect`.
Parametrizing test methods through per-class configuration
============================ 1 failed in 0.12s =============================
This test returns a failure report because ``func(3)`` does not return ``5``.
@@ -127,7 +129,7 @@ Once you develop multiple tests, you may want to group them into a class. pytest
x="hello"
asserthasattr(x,"check")
``pytest`` discovers all tests following its :ref:`Conventions for Python test discovery <test discovery>`, so it finds both ``test_`` prefixed functions. There is no need to subclass anything. We can simply run the module by passing its filename:
``pytest`` discovers all tests following its :ref:`Conventions for Python test discovery <test discovery>`, so it finds both ``test_`` prefixed functions. There is no need to subclass anything, but make sure to prefix your class with ``Test`` otherwise the class will be skipped. We can simply run the module by passing its filename:
..code-block::pytest
@@ -145,6 +147,8 @@ Once you develop multiple tests, you may want to group them into a class. pytest
E + where False = hasattr('hello', 'check')
test_class.py:8: AssertionError
========================= short test summary info ==========================
The first test passed and the second failed. You can easily see the intermediate values in the assertion to help you understand the reason for the failure.
@@ -180,6 +184,8 @@ List the name ``tmpdir`` in the test function signature and ``pytest`` will look
The technical aspects of the Python 2.7 and 3.4 support plan (such as when releases will occurr, how to backport fixes, etc) is described in issue`#5275 <https://github.com/pytest-dev/pytest/issues/5275>`__.
(This section is a transcript from`#5275 <https://github.com/pytest-dev/pytest/issues/5275>`__).
In this section we describe the technical aspects of the Python 2.7 and 3.4 support plan.
What goes into 4.6.X releases
+++++++++++++++++++++++++++++
New 4.6.X releases will contain bug fixes only.
When will 4.6.X releases happen
+++++++++++++++++++++++++++++++
New 4.6.X releases will happen after we have a few bugs in place to release, or if a few weeks have
passed (say a single bug has been fixed a month after the latest 4.6.X release).
No hard rules here, just ballpark.
Who will handle applying bug fixes
++++++++++++++++++++++++++++++++++
We core maintainers expect that people still using Python 2.7/3.4 and being affected by
bugs to step up and provide patches and/or port bug fixes from the active branches.
We will be happy to guide users interested in doing so, so please don't hesitate to ask.
**Backporting changes into 4.6**
Please follow these instructions:
#.``git fetch --all --prune``
#.``git checkout origin/4.6.x -b backport-XXXX`` # use the PR number here
#. Locate the merge commit on the PR, in the *merged* message, for example:
nicoddemus merged commit 0f8b462 into pytest-dev:features
#.``git cherry-pick -m1 REVISION`` # use the revision you found above (``0f8b462``).
#. Open a PR targeting ``4.6.x``:
* Prefix the message with ``[4.6]`` so it is an obvious backport
* Delete the PR body, it usually contains a duplicate commit message.
**Providing new PRs to 4.6**
Fresh pull requests to ``4.6.x`` will be accepted provided that
the equivalent code in the active branches does not contain that bug (for example, a bug is specific
to Python 2 only).
Bug fixes that also happen in the mainstream version should be first fixed
there, and then backported as per instructions above.
@@ -33,7 +33,7 @@ Running ``pytest`` can result in six different exit codes:
:Exit code 4:pytest command line usage error
:Exit code 5:No tests were collected
They are represented by the :class:`_pytest.main.ExitCode` enum. The exit codes being a part of the public API can be imported and accessed directly using:
They are represented by the :class:`_pytest.config.ExitCode` enum. The exit codes being a part of the public API can be imported and accessed directly using:
..code-block::python
@@ -66,8 +66,8 @@ To stop the testing process after the first (N) failures:
..code-block::bash
pytest -x # stop after first failure
pytest --maxfail=2# stop after two failures
pytest -x # stop after first failure
pytest --maxfail=2# stop after two failures
.._select-tests:
@@ -94,8 +94,8 @@ Pytest supports several ways to run and select tests from the command-line.
pytest -k "MyClass and not method"
This will run tests which contain names that match the given *string expression*, which can
include Python operators that use filenames, class names and function names as variables.
This will run tests which contain names that match the given *string expression* (case-insensitive),
which can include Python operators that use filenames, class names and function names as variables.
The example above will run ``TestMyClass.test_something`` but not ``TestMyClass.test_method_simple``.
.._nodeids:
@@ -169,11 +169,11 @@ option you make sure a trace is shown.
Detailed summary report
-----------------------
The ``-r`` flag can be used to display a "short test summary info" at the end of the test session,
making it easy in large test suites to get a clear picture of all failures, skips, xfails, etc.
It defaults to ``fE`` to list failures and errors.
Example:
..code-block::python
@@ -241,7 +241,7 @@ Example:
test_example.py:14: AssertionError
========================= short test summary info ==========================
SKIPPED [1] $REGENDOC_TMPDIR/test_example.py:23: skipping this test
SKIPPED [1] $REGENDOC_TMPDIR/test_example.py:22: skipping this test
XFAIL test_example.py::test_xfail
reason: xfailing this test
XPASS test_example.py::test_xpass always xfail
@@ -261,8 +261,12 @@ Here is the full list of available characters that can be used:
-``X`` - xpassed
-``p`` - passed
-``P`` - passed with output
Special characters for (de)selection of groups:
-``a`` - all except ``pP``
-``A`` - all
-``N`` - none, this can be used to display nothing (since ``fE`` is the default)
More than one character can be used, so for example to only see failed and skipped tests, you can execute:
@@ -296,7 +300,7 @@ More than one character can be used, so for example to only see failed and skipp
test_example.py:14: AssertionError
========================= short test summary info ==========================
FAILED test_example.py::test_fail - assert 0
SKIPPED [1] $REGENDOC_TMPDIR/test_example.py:23: skipping this test
SKIPPED [1] $REGENDOC_TMPDIR/test_example.py:22: skipping this test
@@ -179,11 +179,12 @@ assertion failures. This is provided by "assertion rewriting" which
modifies the parsed AST before it gets compiled to bytecode. This is
done via a :pep:`302` import hook which gets installed early on when
``pytest`` starts up and will perform this rewriting when modules get
imported. However since we do not want to test different bytecode
then you will run in production this hook only rewrites test modules
themselves as well as any modules which are part of plugins. Any
other imported module will not be rewritten and normal assertion
behaviour will happen.
imported. However, since we do not want to test different bytecode
from what you will run in production, this hook only rewrites test modules
themselves (as defined by the :confval:`python_files` configuration option),
and any modules which are part of plugins.
Any other imported module will not be rewritten and normal assertion behaviour
will happen.
If you have assertion helpers in other modules where you would need
assertion rewriting to be enabled you need to ask ``pytest``
@@ -441,8 +442,13 @@ additionally it is possible to copy examples for an example folder before runnin
$REGENDOC_TMPDIR/test_example.py:4: PytestExperimentalApiWarning: testdir.copy_example is an experimental api that may change over time
testdir.copy_example("test_example.py")
test_example.py::test_plugin
$PYTHON_PREFIX/lib/python3.8/site-packages/_pytest/terminal.py:287: PytestDeprecationWarning: TerminalReporter.writer attribute is deprecated, use TerminalReporter._tw instead at your own risk.
See https://docs.pytest.org/en/latest/deprecations.html#terminalreporter-writer for more information.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
