Merge pull request #8131 from bluetech/cherry-pick-release

Merge pull request #8130 from pytest-dev/release-6.2.0

.coveragerc

@@ -27,3 +27,4 @@ exclude_lines =
     ^\s*assert False(,|$)
 
     ^\s*if TYPE_CHECKING:
+    ^\s*@overload( |$)

.github/ISSUE_TEMPLATE/1_bug_report.md

@@ -1,10 +1,16 @@
+---
+name: 🐛 Bug Report
+about: Report errors and problems
+
+---
+
 <!--
 Thanks for submitting an issue!
 
-Here's a quick checklist for what to provide:
+Quick check-list while reporting bugs:
 -->
 
-- [ ] a detailed description of the bug or suggestion
+- [ ] a detailed description of the bug or problem you are having
 - [ ] output of `pip list` from the virtual environment you are using
 - [ ] pytest and operating system versions
 - [ ] minimal example if possible

.github/ISSUE_TEMPLATE/2_feature_request.md

@@ -0,0 +1,25 @@
+---
+name: 🚀 Feature Request
+about: Ideas for new features and improvements
+
+---
+
+<!--
+Thanks for suggesting a feature!
+
+Quick check-list while suggesting features:
+-->
+
+#### What's the problem this feature will solve?
+<!-- What are you trying to do, that you are unable to achieve with pytest as it currently stands? -->
+
+#### Describe the solution you'd like
+<!-- A clear and concise description of what you want to happen. -->
+
+<!-- Provide examples of real-world use cases that this would enable and how it solves the problem described above. -->
+
+#### Alternative Solutions
+<!-- Have you tried to workaround the problem using a pytest plugin or other tools? Or a different approach to solving this issue? Please elaborate here. -->
+
+#### Additional context
+<!-- Add any other context, links, etc. about the feature here. -->

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,5 @@
+blank_issues_enabled: false
+contact_links:
+  - name: ❓ Support Question
+    url: https://github.com/pytest-dev/pytest/discussions
+    about: Use GitHub's new Discussions feature for questions

.github/dependabot.yml

@@ -0,0 +1,11 @@
+version: 2
+updates:
+- package-ecosystem: pip
+  directory: "/testing/plugins_integration"
+  schedule:
+    interval: weekly
+    time: "03:00"
+  open-pull-requests-limit: 10
+  allow:
+  - dependency-type: direct
+  - dependency-type: indirect

.github/workflows/main.yml

@@ -6,7 +6,8 @@ on:
       - master
       - "[0-9]+.[0-9]+.x"
     tags:
-      - "*"
+      - "[0-9]+.[0-9]+.[0-9]+"
+      - "[0-9]+.[0-9]+.[0-9]+rc[0-9]+"
 
   pull_request:
     branches:
@@ -16,18 +17,17 @@ on:
 jobs:
   build:
     runs-on: ${{ matrix.os }}
+    timeout-minutes: 30
 
     strategy:
       fail-fast: false
       matrix:
         name: [
-          "windows-py35",
           "windows-py36",
           "windows-py37",
           "windows-py37-pluggy",
           "windows-py38",
 
-          "ubuntu-py35",
           "ubuntu-py36",
           "ubuntu-py37",
           "ubuntu-py37-pluggy",
@@ -41,14 +41,10 @@ jobs:
 
           "docs",
           "doctesting",
+          "plugins",
         ]
 
         include:
-          - name: "windows-py35"
-            python: "3.5"
-            os: windows-latest
-            tox_env: "py35-xdist"
-            use_coverage: true
           - name: "windows-py36"
             python: "3.6"
             os: windows-latest
@@ -67,10 +63,6 @@ jobs:
             tox_env: "py38-unittestextras"
             use_coverage: true
 
-          - name: "ubuntu-py35"
-            python: "3.5"
-            os: ubuntu-latest
-            tox_env: "py35-xdist"
           - name: "ubuntu-py36"
             python: "3.6"
             os: ubuntu-latest
@@ -78,7 +70,7 @@ jobs:
           - name: "ubuntu-py37"
             python: "3.7"
             os: ubuntu-latest
-            tox_env: "py37-lsof-numpy-oldattrs-pexpect"
+            tox_env: "py37-lsof-numpy-pexpect"
             use_coverage: true
           - name: "ubuntu-py37-pluggy"
             python: "3.7"
@@ -93,7 +85,7 @@ jobs:
             os: ubuntu-latest
             tox_env: "py38-xdist"
           - name: "ubuntu-py39"
-            python: "3.9-dev"
+            python: "3.9"
             os: ubuntu-latest
             tox_env: "py39-xdist"
           - name: "ubuntu-pypy3"
@@ -111,6 +103,11 @@ jobs:
             tox_env: "py38-xdist"
             use_coverage: true
 
+          - name: "plugins"
+            python: "3.7"
+            os: ubuntu-latest
+            tox_env: "plugins"
+
           - name: "docs"
             python: "3.7"
             os: ubuntu-latest
@@ -127,12 +124,6 @@ jobs:
         fetch-depth: 0
     - name: Set up Python ${{ matrix.python }}
       uses: actions/setup-python@v2
-      if: matrix.python != '3.9-dev'
-      with:
-        python-version: ${{ matrix.python }}
-    - name: Set up Python ${{ matrix.python }} (deadsnakes)
-      uses: deadsnakes/action@v1.0.0
-      if: matrix.python == '3.9-dev'
       with:
         python-version: ${{ matrix.python }}
     - name: Install dependencies
@@ -169,18 +160,22 @@ jobs:
     - uses: actions/checkout@v2
     - uses: actions/setup-python@v2
     - name: set PY
-      run: echo "::set-env name=PY::$(python -c 'import hashlib, sys;print(hashlib.sha256(sys.version.encode()+sys.executable.encode()).hexdigest())')"
-    - uses: actions/cache@v1
+      run: echo "name=PY::$(python -c 'import hashlib, sys;print(hashlib.sha256(sys.version.encode()+sys.executable.encode()).hexdigest())')" >> $GITHUB_ENV
+    - uses: actions/cache@v2
       with:
         path: ~/.cache/pre-commit
         key: pre-commit|${{ env.PY }}|${{ hashFiles('.pre-commit-config.yaml') }}
-    - run: pip install tox
+    - name: Install dependencies
+      run: |
+        python -m pip install --upgrade pip
+        pip install tox
     - run: tox -e linting
 
   deploy:
     if: github.event_name == 'push' && startsWith(github.event.ref, 'refs/tags') && github.repository == 'pytest-dev/pytest'
 
     runs-on: ubuntu-latest
+    timeout-minutes: 30
 
     needs: [build]
 

.gitignore

@@ -34,6 +34,7 @@ issue/
 env/
 .env/
 .venv/
+/pythonenv*/
 3rdparty/
 .tox
 .cache

.pre-commit-config.yaml

@@ -5,12 +5,12 @@ repos:
     -   id: black
         args: [--safe, --quiet]
 -   repo: https://github.com/asottile/blacken-docs
-    rev: v1.7.0
+    rev: v1.8.0
     hooks:
     -   id: blacken-docs
         additional_dependencies: [black==19.10b0]
 -   repo: https://github.com/pre-commit/pre-commit-hooks
-    rev: v3.1.0
+    rev: v3.2.0
     hooks:
     -   id: trailing-whitespace
     -   id: end-of-file-fixer
@@ -21,33 +21,44 @@ repos:
         exclude: _pytest/(debugging|hookspec).py
         language_version: python3
 -   repo: https://gitlab.com/pycqa/flake8
-    rev: 3.8.2
+    rev: 3.8.3
     hooks:
     -   id: flake8
         language_version: python3
-        additional_dependencies: [flake8-typing-imports==1.9.0]
+        additional_dependencies:
+          - flake8-typing-imports==1.9.0
+          - flake8-docstrings==1.5.0
 -   repo: https://github.com/asottile/reorder_python_imports
-    rev: v2.3.0
+    rev: v2.3.5
     hooks:
     -   id: reorder-python-imports
-        args: ['--application-directories=.:src', --py3-plus]
+        args: ['--application-directories=.:src', --py36-plus]
 -   repo: https://github.com/asottile/pyupgrade
-    rev: v2.4.4
+    rev: v2.7.2
     hooks:
     -   id: pyupgrade
-        args: [--py3-plus]
+        args: [--py36-plus]
 -   repo: https://github.com/asottile/setup-cfg-fmt
-    rev: v1.9.0
+    rev: v1.11.0
     hooks:
     -   id: setup-cfg-fmt
         # TODO: when upgrading setup-cfg-fmt this can be removed
         args: [--max-py-version=3.9]
+-   repo: https://github.com/pre-commit/pygrep-hooks
+    rev: v1.6.0
+    hooks:
+    -   id: python-use-type-annotations
 -   repo: https://github.com/pre-commit/mirrors-mypy
-    rev: v0.780  # NOTE: keep this in sync with setup.cfg.
+    rev: v0.790
     hooks:
     -   id: mypy
         files: ^(src/|testing/)
         args: []
+        additional_dependencies:
+          - iniconfig>=1.1.0
+          - py>=1.8.2
+          - attrs>=19.2.0
+          - packaging
 -   repo: local
     hooks:
     -   id: rst
@@ -70,9 +81,11 @@ repos:
                 _code\.|
                 builtin\.|
                 code\.|
-                io\.(BytesIO|saferepr|TerminalWriter)|
+                io\.|
                 path\.local\.sysfind|
                 process\.|
-                std\.
+                std\.|
+                error\.|
+                xml\.
             )
         types: [python]

.readthedocs.yml

@@ -0,0 +1,12 @@
+version: 2
+
+python:
+   version: 3.7
+   install:
+      - requirements: doc/en/requirements.txt
+      - method: pip
+        path: .
+
+formats:
+  - epub
+  - pdf

.travis.yml

@@ -1,60 +0,0 @@
-language: python
-dist: trusty
-python: '3.5.1'
-cache: false
-
-env:
-  global:
-    - PYTEST_ADDOPTS=-vv
-
-# setuptools-scm needs all tags in order to obtain a proper version
-git:
-  depth: false
-
-install:
-  - python -m pip install --upgrade --pre tox
-
-jobs:
-  include:
-    # Coverage for Python 3.5.{0,1} specific code, mostly typing related.
-    - env: TOXENV=py35 PYTEST_COVERAGE=1 PYTEST_ADDOPTS="-k test_raises_cyclic_reference"
-      before_install:
-        # Work around https://github.com/jaraco/zipp/issues/40.
-        - python -m pip install -U 'setuptools>=34.4.0' virtualenv==16.7.9
-
-before_script:
-  - |
-    # Do not (re-)upload coverage with cron runs.
-    if [[ "$TRAVIS_EVENT_TYPE" = cron ]]; then
-      PYTEST_COVERAGE=0
-    fi
-  - |
-    if [[ "$PYTEST_COVERAGE" = 1 ]]; then
-      export COVERAGE_FILE="$PWD/.coverage"
-      export COVERAGE_PROCESS_START="$PWD/.coveragerc"
-      export _PYTEST_TOX_COVERAGE_RUN="coverage run -m"
-      export _PYTEST_TOX_EXTRA_DEP=coverage-enable-subprocess
-    fi
-
-script: tox
-
-after_success:
-  - |
-    if [[ "$PYTEST_COVERAGE" = 1 ]]; then
-      env CODECOV_NAME="$TOXENV-$TRAVIS_OS_NAME" scripts/report-coverage.sh -F Travis
-    fi
-
-notifications:
-  irc:
-    channels:
-      - "chat.freenode.net#pytest"
-    on_success: change
-    on_failure: change
-    skip_join: true
-  email:
-    - pytest-commit@python.org
-
-branches:
-  only:
-    - master
-    - /^\d+\.\d+\.x$/

AUTHORS

@@ -32,6 +32,7 @@ Anthony Sottile
 Anton Lodder
 Antony Lee
 Arel Cordero
+Ariel Pillemer
 Armin Rigo
 Aron Coyle
 Aron Curzon
@@ -60,6 +61,7 @@ Christian Fetzer
 Christian Neumüller
 Christian Theunert
 Christian Tismer
+Christine Mecklenborg
 Christoph Buelter
 Christopher Dignam
 Christopher Gilling
@@ -87,6 +89,7 @@ Dhiren Serai
 Diego Russo
 Dmitry Dygalo
 Dmitry Pribysh
+Dominic Mortlock
 Duncan Betts
 Edison Gustavo Muenz
 Edoardo Batini
@@ -107,6 +110,7 @@ Florian Bruhin
 Florian Dahlitz
 Floris Bruynooghe
 Gabriel Reis
+Garvit Shubham
 Gene Wood
 George Kussumoto
 Georgy Dyuldin
@@ -129,6 +133,7 @@ Ilya Konstantinov
 Ionuț Turturică
 Iwan Briquemont
 Jaap Broekhuizen
+Jakob van Santen
 Jakub Mitoraj
 Jan Balster
 Janne Vanhala
@@ -151,7 +156,9 @@ Joshua Bronson
 Jurko Gospodnetić
 Justyna Janczyszyn
 Kale Kundert
+Kamran Ahmad
 Karl O. Pinc
+Karthikeyan Singaravelan
 Katarzyna Jachim
 Katarzyna Król
 Katerina Koukiou
@@ -194,6 +201,7 @@ Matthias Hafner
 Maxim Filipenko
 Maximilian Cosmo Sitter
 mbyt
+Mickey Pashov
 Michael Aquilina
 Michael Birtwell
 Michael Droettboom
@@ -226,11 +234,14 @@ Pauli Virtanen
 Pavel Karateev
 Paweł Adamczak
 Pedro Algarvio
+Petter Strandmark
 Philipp Loose
 Pieter Mulder
 Piotr Banaszkiewicz
 Piotr Helm
+Prakhar Gurunani
 Prashant Anand
+Prashant Sharma
 Pulkit Goyal
 Punyashloka Biswal
 Quentin Pradet
@@ -255,10 +266,12 @@ Ryan Wooden
 Samuel Dion-Girardeau
 Samuel Searles-Bryant
 Samuele Pedroni
+Sanket Duthade
 Sankt Petersbug
 Segev Finer
 Serhii Mozghovyi
 Seth Junot
+Shubham Adep
 Simon Gomizelj
 Simon Kerr
 Skylar Downes
@@ -273,6 +286,7 @@ Sven-Hendrik Haase
 Sylvain Marié
 Tadek Teleżyński
 Takafumi Arakaki
+Tanvi Mehta
 Tarcisio Fischer
 Tareq Alayan
 Ted Xiao
@@ -309,3 +323,4 @@ Xuecong Liao
 Yoav Caspi
 Zac Hatfield-Dodds
 Zoltán Máté
+Zsolt Cserna

CONTRIBUTING.rst

@@ -89,6 +89,38 @@ without using a local copy.  This can be convenient for small fixes.
     The built documentation should be available in ``doc/en/_build/html``,
     where 'en' refers to the documentation language.
 
+Pytest has an API reference which in large part is
+`generated automatically <https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html>`_
+from the docstrings of the documented items. Pytest uses the
+`Sphinx docstring format <https://sphinx-rtd-tutorial.readthedocs.io/en/latest/docstrings.html>`_.
+For example:
+
+.. code-block:: python
+
+    def my_function(arg: ArgType) -> Foo:
+        """Do important stuff.
+
+        More detailed info here, in separate paragraphs from the subject line.
+        Use proper sentences -- start sentences with capital letters and end
+        with periods.
+
+        Can include annotated documentation:
+
+        :param short_arg: An argument which determines stuff.
+        :param long_arg:
+            A long explanation which spans multiple lines, overflows
+            like this.
+        :returns: The result.
+        :raises ValueError:
+            Detailed information when this can happen.
+
+        .. versionadded:: 6.0
+
+        Including types into the annotations above is not necessary when
+        type-hinting is being used (as in this example).
+        """
+
+
 .. _submitplugin:
 
 Submitting Plugins to pytest-dev
@@ -99,8 +131,6 @@ in repositories living under the ``pytest-dev`` organisations:
 
 - `pytest-dev on GitHub <https://github.com/pytest-dev>`_
 
-- `pytest-dev on Bitbucket <https://bitbucket.org/pytest-dev>`_
-
 All pytest-dev Contributors team members have write access to all contained
 repositories.  Pytest core and plugins are generally developed
 using `pull requests`_ to respective repositories.
@@ -116,16 +146,17 @@ You can submit your plugin by subscribing to the `pytest-dev mail list
 mail pointing to your existing pytest plugin repository which must have
 the following:
 
-- PyPI presence with a ``setup.py`` that contains a license, ``pytest-``
+- PyPI presence with packaging metadata that contains a ``pytest-``
   prefixed name, version number, authors, short and long description.
 
-- a ``tox.ini`` for running tests using `tox <https://tox.readthedocs.io>`_.
+- a  `tox configuration <https://tox.readthedocs.io/en/latest/config.html#configuration-discovery>`_
+  for running tests using `tox <https://tox.readthedocs.io>`_.
 
-- a ``README.txt`` describing how to use the plugin and on which
+- a ``README`` describing how to use the plugin and on which
   platforms it runs.
 
-- a ``LICENSE.txt`` file or equivalent containing the licensing
-  information, with matching info in ``setup.py``.
+- a ``LICENSE`` file containing the licensing information, with
+  matching info in its packaging metadata.
 
 - an issue tracker for bug reports and enhancement requests.
 
@@ -268,12 +299,6 @@ Here is a simple overview, with pytest-specific bits:
 
        $ pytest testing/test_config.py
 
-
-#. Commit and push once your tests pass and you are happy with your change(s)::
-
-    $ git commit -a -m "<commit message>"
-    $ git push -u
-
 #. Create a new changelog entry in ``changelog``. The file should be named ``<issueid>.<type>.rst``,
    where *issueid* is the number of the issue related to the change and *type* is one of
    ``feature``, ``improvement``, ``bugfix``, ``doc``, ``deprecation``, ``breaking``, ``vendor``
@@ -282,6 +307,11 @@ Here is a simple overview, with pytest-specific bits:
 
 #. Add yourself to ``AUTHORS`` file if not there yet, in alphabetical order.
 
+#. Commit and push once your tests pass and you are happy with your change(s)::
+
+    $ git commit -a -m "<commit message>"
+    $ git push -u
+
 #. Finally, submit a pull request through the GitHub website using this data::
 
     head-fork: YOUR_GITHUB_USERNAME/pytest
@@ -375,6 +405,27 @@ actual latest release). The procedure for this is:
    * Delete the PR body, it usually contains a duplicate commit message.
 
 
+Who does the backporting
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+As mentioned above, bugs should first be fixed on ``master`` (except in rare occasions
+that a bug only happens in a previous release). So who should do the backport procedure described
+above?
+
+1. If the bug was fixed by a core developer, it is the main responsibility of that core developer
+   to do the backport.
+2. However, often the merge is done by another maintainer, in which case it is nice of them to
+   do the backport procedure if they have the time.
+3. For bugs submitted by non-maintainers, it is expected that a core developer will to do
+   the backport, normally the one that merged the PR on ``master``.
+4. If a non-maintainers notices a bug which is fixed on ``master`` but has not been backported
+   (due to maintainers forgetting to apply the *needs backport* label, or just plain missing it),
+   they are also welcome to open a PR with the backport. The procedure is simple and really
+   helps with the maintenance of the project.
+
+All the above are not rules, but merely some guidelines/suggestions on what we should expect
+about backports.
+
 Handling stale issues/PRs
 -------------------------
 

README.rst

@@ -22,8 +22,8 @@
 .. image:: https://travis-ci.org/pytest-dev/pytest.svg?branch=master
     :target: https://travis-ci.org/pytest-dev/pytest
 
-.. image:: https://dev.azure.com/pytest-dev/pytest/_apis/build/status/pytest-CI?branchName=master
-    :target: https://dev.azure.com/pytest-dev/pytest
+.. image:: https://github.com/pytest-dev/pytest/workflows/main/badge.svg
+    :target: https://github.com/pytest-dev/pytest/actions?query=workflow%3Amain
 
 .. image:: https://img.shields.io/badge/code%20style-black-000000.svg
     :target: https://github.com/psf/black
@@ -77,21 +77,21 @@ Due to ``pytest``'s detailed assertion introspection, only plain ``assert`` stat
 Features
 --------
 
-- Detailed info on failing `assert statements <https://docs.pytest.org/en/stable/assert.html>`_ (no need to remember ``self.assert*`` names);
+- Detailed info on failing `assert statements <https://docs.pytest.org/en/stable/assert.html>`_ (no need to remember ``self.assert*`` names)
 
 - `Auto-discovery
   <https://docs.pytest.org/en/stable/goodpractices.html#python-test-discovery>`_
-  of test modules and functions;
+  of test modules and functions
 
 - `Modular fixtures <https://docs.pytest.org/en/stable/fixture.html>`_ for
-  managing small or parametrized long-lived test resources;
+  managing small or parametrized long-lived test resources
 
 - Can run `unittest <https://docs.pytest.org/en/stable/unittest.html>`_ (or trial),
-  `nose <https://docs.pytest.org/en/stable/nose.html>`_ test suites out of the box;
+  `nose <https://docs.pytest.org/en/stable/nose.html>`_ test suites out of the box
 
-- Python 3.5+ and PyPy3;
+- Python 3.6+ and PyPy3
 
-- Rich plugin architecture, with over 850+ `external plugins <http://plugincompat.herokuapp.com>`_ and thriving community;
+- Rich plugin architecture, with over 850+ `external plugins <http://plugincompat.herokuapp.com>`_ and thriving community
 
 
 Documentation

RELEASING.rst

@@ -5,37 +5,85 @@ Our current policy for releasing is to aim for a bug-fix release every few weeks
 is to get fixes and new features out instead of trying to cram a ton of features into a release and by consequence
 taking a lot of time to make a new one.
 
+The git commands assume the following remotes are setup:
+
+* ``origin``: your own fork of the repository.
+* ``upstream``: the ``pytest-dev/pytest`` official repository.
+
 Preparing: Automatic Method
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 We have developed an automated workflow for releases, that uses GitHub workflows and is triggered
-by opening an issue or issuing a comment one.
+by opening an issue.
 
-The comment must be in the form::
+Bug-fix releases
+^^^^^^^^^^^^^^^^
 
-    @pytestbot please prepare release from BRANCH
+A bug-fix release is always done from a maintenance branch, so for example to release bug-fix
+``5.1.2``, open a new issue and add this comment to the body::
 
-Where ``BRANCH`` is ``master`` or one of the maintenance branches.
+    @pytestbot please prepare release from 5.1.x
 
-For major releases the comment must be in the form::
+Where ``5.1.x`` is the maintenance branch for the ``5.1`` series.
 
-    @pytestbot please prepare major release from master
+The automated workflow will publish a PR for a branch ``release-5.1.2``
+and notify it as a comment in the issue.
 
-After that, the workflow should publish a PR and notify that it has done so as a comment
-in the original issue.
+Minor releases
+^^^^^^^^^^^^^^
+
+1. Create a new maintenance branch from ``master``::
+
+        git fetch --all
+        git branch 5.2.x upstream/master
+        git push upstream 5.2.x
+
+2. Open a new issue and add this comment to the body::
+
+    @pytestbot please prepare release from 5.2.x
+
+The automated workflow will publish a PR for a branch ``release-5.2.0`` and
+notify it as a comment in the issue.
+
+Major and release candidates
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+1. Create a new maintenance branch from ``master``::
+
+        git fetch --all
+        git branch 6.0.x upstream/master
+        git push upstream 6.0.x
+
+2. For a **major release**, open a new issue and add this comment in the body::
+
+        @pytestbot please prepare major release from 6.0.x
+
+   For a **release candidate**, the comment must be (TODO: `#7551 <https://github.com/pytest-dev/pytest/issues/7551>`__)::
+
+        @pytestbot please prepare release candidate from 6.0.x
+
+The automated workflow will publish a PR for a branch ``release-6.0.0`` and
+notify it as a comment in the issue.
+
+At this point on, this follows the same workflow as other maintenance branches: bug-fixes are merged
+into ``master`` and ported back to the maintenance branch, even for release candidates.
+
+**A note about release candidates**
+
+During release candidates we can merge small improvements into
+the maintenance branch before releasing the final major version, however we must take care
+to avoid introducing big changes at this stage.
 
 Preparing: Manual Method
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. important::
-
-    pytest releases must be prepared on **Linux** because the docs and examples expect
-    to be executed on that platform.
+**Important**: pytest releases must be prepared on **Linux** because the docs and examples expect
+to be executed on that platform.
 
 To release a version ``MAJOR.MINOR.PATCH``, follow these steps:
 
-#. For major and minor releases, create a new branch ``MAJOR.MINOR.x`` from the
-   latest ``master`` and push it to the ``pytest-dev/pytest`` repo.
+#. For major and minor releases, create a new branch ``MAJOR.MINOR.x`` from
+   ``upstream/master`` and push it to ``upstream``.
 
 #. Create a branch ``release-MAJOR.MINOR.PATCH`` from the ``MAJOR.MINOR.x`` branch.
 
@@ -56,9 +104,10 @@ Releasing
 Both automatic and manual processes described above follow the same steps from this point onward.
 
 #. After all tests pass and the PR has been approved, tag the release commit
-   in the ``MAJOR.MINOR.x`` branch and push it. This will publish to PyPI::
+   in the ``release-MAJOR.MINOR.PATCH`` branch and push it. This will publish to PyPI::
 
-     git tag MAJOR.MINOR.PATCH
+     git fetch --all
+     git tag MAJOR.MINOR.PATCH upstream/release-MAJOR.MINOR.PATCH
      git push git@github.com:pytest-dev/pytest.git MAJOR.MINOR.PATCH
 
    Wait for the deploy to complete, then make sure it is `available on PyPI <https://pypi.org/project/pytest>`_.
@@ -69,9 +118,17 @@ Both automatic and manual processes described above follow the same steps from t
 
        git fetch --all --prune
        git checkout origin/master -b cherry-pick-release
-       git cherry-pick --no-commit -m1 origin/MAJOR.MINOR.x
-       git checkout origin/master -- changelog
-       git commit  # no arguments
+       git cherry-pick -x -m1 upstream/MAJOR.MINOR.x
+
+#. Open a PR for ``cherry-pick-release`` and merge it once CI passes. No need to wait for approvals if there were no conflicts on the previous step.
+
+#. For major and minor releases, tag the release cherry-pick merge commit in master with
+   a dev tag for the next feature release::
+
+       git checkout master
+       git pull
+       git tag MAJOR.{MINOR+1}.0.dev0
+       git push git@github.com:pytest-dev/pytest.git MAJOR.{MINOR+1}.0.dev0
 
 #. Send an email announcement with the contents from::
 

bench/unit_test.py

@@ -0,0 +1,13 @@
+from unittest import TestCase  # noqa: F401
+
+for i in range(15000):
+    exec(
+        f"""
+class Test{i}(TestCase):
+    @classmethod
+    def setUpClass(cls): pass
+    def test_1(self): pass
+    def test_2(self): pass
+    def test_3(self): pass
+"""
+    )

bench/xunit.py

@@ -0,0 +1,11 @@
+for i in range(5000):
+    exec(
+        f"""
+class Test{i}:
+    @classmethod
+    def setup_class(cls): pass
+    def test_1(self): pass
+    def test_2(self): pass
+    def test_3(self): pass
+"""
+    )

doc/en/adopt.rst

@@ -45,7 +45,7 @@ Partner projects, sign up here! (by 22 March)
 What does it mean to "adopt pytest"?
 -----------------------------------------
 
-There can be many different definitions of "success". Pytest can run many `nose and unittest`_ tests by default, so using pytest as your testrunner may be possible from day 1. Job done, right?
+There can be many different definitions of "success". Pytest can run many nose_ and unittest_ tests by default, so using pytest as your testrunner may be possible from day 1. Job done, right?
 
 Progressive success might look like:
 
@@ -63,7 +63,8 @@ Progressive success might look like:
 
 It may be after the month is up, the partner project decides that pytest is not right for it. That's okay - hopefully the pytest team will also learn something about its weaknesses or deficiencies.
 
-.. _`nose and unittest`: faq.html#how-does-pytest-relate-to-nose-and-unittest
+.. _nose: nose.html
+.. _unittest: unittest.html
 .. _assert: assert.html
 .. _pycmd: https://bitbucket.org/hpk42/pycmd/overview
 .. _`setUp/tearDown methods`: xunit_setup.html

doc/en/announce/index.rst

@@ -6,6 +6,12 @@ Release announcements
    :maxdepth: 2
 
 
+   release-6.2.0
+   release-6.1.2
+   release-6.1.1
+   release-6.1.0
+   release-6.0.2
+   release-6.0.1
    release-6.0.0
    release-6.0.0rc1
    release-5.4.3

doc/en/announce/release-2.3.0.rst

@@ -94,7 +94,7 @@ Changes between 2.2.4 and 2.3.0
 - pluginmanager.register(...) now raises ValueError if the
   plugin has been already registered or the name is taken
 
-- fix issue159: improve http://pytest.org/en/stable/faq.html
+- fix issue159: improve https://docs.pytest.org/en/6.0.1/faq.html
   especially with respect to the "magic" history, also mention
   pytest-django, trial and unittest integration.
 

doc/en/announce/release-2.5.1.rst

@@ -1,7 +1,7 @@
 pytest-2.5.1: fixes and new home page styling
 ===========================================================================
 
-pytest is a mature Python testing tool with more than a 1000 tests
+pytest is a mature Python testing tool with more than 1000 tests
 against itself, passing on many different interpreters and platforms.
 
 The 2.5.1 release maintains the "zero-reported-bugs" promise by fixing

doc/en/announce/release-2.5.2.rst

@@ -1,7 +1,7 @@
 pytest-2.5.2: fixes
 ===========================================================================
 
-pytest is a mature Python testing tool with more than a 1000 tests
+pytest is a mature Python testing tool with more than 1000 tests
 against itself, passing on many different interpreters and platforms.
 
 The 2.5.2 release fixes a few bugs with two maybe-bugs remaining and

doc/en/announce/release-2.6.0.rst

@@ -1,7 +1,7 @@
 pytest-2.6.0: shorter tracebacks, new warning system, test runner compat
 ===========================================================================
 
-pytest is a mature Python testing tool with more than a 1000 tests
+pytest is a mature Python testing tool with more than 1000 tests
 against itself, passing on many different interpreters and platforms.
 
 The 2.6.0 release should be drop-in backward compatible to 2.5.2 and

doc/en/announce/release-2.6.1.rst

@@ -1,7 +1,7 @@
 pytest-2.6.1: fixes and new xfail feature
 ===========================================================================
 
-pytest is a mature Python testing tool with more than a 1100 tests
+pytest is a mature Python testing tool with more than 1100 tests
 against itself, passing on many different interpreters and platforms.
 The 2.6.1 release is drop-in compatible to 2.5.2 and actually fixes some
 regressions introduced with 2.6.0.  It also brings a little feature

doc/en/announce/release-2.6.2.rst

@@ -1,7 +1,7 @@
 pytest-2.6.2: few fixes and cx_freeze support
 ===========================================================================
 
-pytest is a mature Python testing tool with more than a 1100 tests
+pytest is a mature Python testing tool with more than 1100 tests
 against itself, passing on many different interpreters and platforms.
 This release is drop-in compatible to 2.5.2 and 2.6.X.  It also
 brings support for including pytest with cx_freeze or similar

doc/en/announce/release-2.6.3.rst

@@ -1,7 +1,7 @@
 pytest-2.6.3: fixes and little improvements
 ===========================================================================
 
-pytest is a mature Python testing tool with more than a 1100 tests
+pytest is a mature Python testing tool with more than 1100 tests
 against itself, passing on many different interpreters and platforms.
 This release is drop-in compatible to 2.5.2 and 2.6.X.
 See below for the changes and see docs at:

doc/en/announce/release-2.7.0.rst

@@ -1,7 +1,7 @@
 pytest-2.7.0: fixes, features, speed improvements
 ===========================================================================
 
-pytest is a mature Python testing tool with more than a 1100 tests
+pytest is a mature Python testing tool with more than 1100 tests
 against itself, passing on many different interpreters and platforms.
 This release is supposed to be drop-in compatible to 2.6.X.
 

doc/en/announce/release-2.7.1.rst

@@ -1,7 +1,7 @@
 pytest-2.7.1: bug fixes
 =======================
 
-pytest is a mature Python testing tool with more than a 1100 tests
+pytest is a mature Python testing tool with more than 1100 tests
 against itself, passing on many different interpreters and platforms.
 This release is supposed to be drop-in compatible to 2.7.0.
 

doc/en/announce/release-2.7.2.rst

@@ -1,7 +1,7 @@
 pytest-2.7.2: bug fixes
 =======================
 
-pytest is a mature Python testing tool with more than a 1100 tests
+pytest is a mature Python testing tool with more than 1100 tests
 against itself, passing on many different interpreters and platforms.
 This release is supposed to be drop-in compatible to 2.7.1.
 

doc/en/announce/release-2.8.2.rst

@@ -1,7 +1,7 @@
 pytest-2.8.2: bug fixes
 =======================
 
-pytest is a mature Python testing tool with more than a 1100 tests
+pytest is a mature Python testing tool with more than 1100 tests
 against itself, passing on many different interpreters and platforms.
 This release is supposed to be drop-in compatible to 2.8.1.
 

doc/en/announce/release-2.8.3.rst

@@ -1,7 +1,7 @@
 pytest-2.8.3: bug fixes
 =======================
 
-pytest is a mature Python testing tool with more than a 1100 tests
+pytest is a mature Python testing tool with more than 1100 tests
 against itself, passing on many different interpreters and platforms.
 This release is supposed to be drop-in compatible to 2.8.2.
 

doc/en/announce/release-2.8.4.rst

@@ -1,7 +1,7 @@
 pytest-2.8.4
 ============
 
-pytest is a mature Python testing tool with more than a 1100 tests
+pytest is a mature Python testing tool with more than 1100 tests
 against itself, passing on many different interpreters and platforms.
 This release is supposed to be drop-in compatible to 2.8.2.
 

doc/en/announce/release-2.8.5.rst

@@ -1,7 +1,7 @@
 pytest-2.8.5
 ============
 
-pytest is a mature Python testing tool with more than a 1100 tests
+pytest is a mature Python testing tool with more than 1100 tests
 against itself, passing on many different interpreters and platforms.
 This release is supposed to be drop-in compatible to 2.8.4.
 

doc/en/announce/release-2.8.6.rst

@@ -1,7 +1,7 @@
 pytest-2.8.6
 ============
 
-pytest is a mature Python testing tool with more than a 1100 tests
+pytest is a mature Python testing tool with more than 1100 tests
 against itself, passing on many different interpreters and platforms.
 This release is supposed to be drop-in compatible to 2.8.5.
 

doc/en/announce/release-2.8.7.rst

@@ -4,7 +4,7 @@ pytest-2.8.7
 This is a hotfix release to solve a regression
 in the builtin monkeypatch plugin that got introduced in 2.8.6.
 
-pytest is a mature Python testing tool with more than a 1100 tests
+pytest is a mature Python testing tool with more than 1100 tests
 against itself, passing on many different interpreters and platforms.
 This release is supposed to be drop-in compatible to 2.8.5.
 

doc/en/announce/release-2.9.0.rst

@@ -1,7 +1,7 @@
 pytest-2.9.0
 ============
 
-pytest is a mature Python testing tool with more than a 1100 tests
+pytest is a mature Python testing tool with more than 1100 tests
 against itself, passing on many different interpreters and platforms.
 
 See below for the changes and see docs at:

doc/en/announce/release-2.9.1.rst

@@ -1,7 +1,7 @@
 pytest-2.9.1
 ============
 
-pytest is a mature Python testing tool with more than a 1100 tests
+pytest is a mature Python testing tool with more than 1100 tests
 against itself, passing on many different interpreters and platforms.
 
 See below for the changes and see docs at:

doc/en/announce/release-2.9.2.rst

@@ -1,7 +1,7 @@
 pytest-2.9.2
 ============
 
-pytest is a mature Python testing tool with more than a 1100 tests
+pytest is a mature Python testing tool with more than 1100 tests
 against itself, passing on many different interpreters and platforms.
 
 See below for the changes and see docs at:

doc/en/announce/release-3.0.0.rst

@@ -3,7 +3,7 @@ pytest-3.0.0
 
 The pytest team is proud to announce the 3.0.0 release!
 
-pytest is a mature Python testing tool with more than a 1600 tests
+pytest is a mature Python testing tool with more than 1600 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a lot of bugs fixes and improvements, and much of

doc/en/announce/release-3.1.0.rst

@@ -3,7 +3,7 @@ pytest-3.1.0
 
 The pytest team is proud to announce the 3.1.0 release!
 
-pytest is a mature Python testing tool with more than a 1600 tests
+pytest is a mature Python testing tool with more than 1600 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a bugs fixes and improvements, so users are encouraged

doc/en/announce/release-3.10.0.rst

@@ -3,7 +3,7 @@ pytest-3.10.0
 
 The pytest team is proud to announce the 3.10.0 release!
 
-pytest is a mature Python testing tool with more than a 2000 tests
+pytest is a mature Python testing tool with more than 2000 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-3.2.0.rst

@@ -3,7 +3,7 @@ pytest-3.2.0
 
 The pytest team is proud to announce the 3.2.0 release!
 
-pytest is a mature Python testing tool with more than a 1600 tests
+pytest is a mature Python testing tool with more than 1600 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-3.3.0.rst

@@ -3,7 +3,7 @@ pytest-3.3.0
 
 The pytest team is proud to announce the 3.3.0 release!
 
-pytest is a mature Python testing tool with more than a 1600 tests
+pytest is a mature Python testing tool with more than 1600 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-3.4.0.rst

@@ -3,7 +3,7 @@ pytest-3.4.0
 
 The pytest team is proud to announce the 3.4.0 release!
 
-pytest is a mature Python testing tool with more than a 1600 tests
+pytest is a mature Python testing tool with more than 1600 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-3.5.0.rst

@@ -3,7 +3,7 @@ pytest-3.5.0
 
 The pytest team is proud to announce the 3.5.0 release!
 
-pytest is a mature Python testing tool with more than a 1600 tests
+pytest is a mature Python testing tool with more than 1600 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-3.6.0.rst

@@ -3,7 +3,7 @@ pytest-3.6.0
 
 The pytest team is proud to announce the 3.6.0 release!
 
-pytest is a mature Python testing tool with more than a 1600 tests
+pytest is a mature Python testing tool with more than 1600 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-3.7.0.rst

@@ -3,7 +3,7 @@ pytest-3.7.0
 
 The pytest team is proud to announce the 3.7.0 release!
 
-pytest is a mature Python testing tool with more than a 2000 tests
+pytest is a mature Python testing tool with more than 2000 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-3.8.0.rst

@@ -3,7 +3,7 @@ pytest-3.8.0
 
 The pytest team is proud to announce the 3.8.0 release!
 
-pytest is a mature Python testing tool with more than a 2000 tests
+pytest is a mature Python testing tool with more than 2000 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-3.9.0.rst

@@ -3,7 +3,7 @@ pytest-3.9.0
 
 The pytest team is proud to announce the 3.9.0 release!
 
-pytest is a mature Python testing tool with more than a 2000 tests
+pytest is a mature Python testing tool with more than 2000 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-4.0.0.rst

@@ -3,7 +3,7 @@ pytest-4.0.0
 
 The pytest team is proud to announce the 4.0.0 release!
 
-pytest is a mature Python testing tool with more than a 2000 tests
+pytest is a mature Python testing tool with more than 2000 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-4.1.0.rst

@@ -3,7 +3,7 @@ pytest-4.1.0
 
 The pytest team is proud to announce the 4.1.0 release!
 
-pytest is a mature Python testing tool with more than a 2000 tests
+pytest is a mature Python testing tool with more than 2000 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-4.2.0.rst

@@ -3,7 +3,7 @@ pytest-4.2.0
 
 The pytest team is proud to announce the 4.2.0 release!
 
-pytest is a mature Python testing tool with more than a 2000 tests
+pytest is a mature Python testing tool with more than 2000 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-4.3.0.rst

@@ -3,7 +3,7 @@ pytest-4.3.0
 
 The pytest team is proud to announce the 4.3.0 release!
 
-pytest is a mature Python testing tool with more than a 2000 tests
+pytest is a mature Python testing tool with more than 2000 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-4.4.0.rst

@@ -3,7 +3,7 @@ pytest-4.4.0
 
 The pytest team is proud to announce the 4.4.0 release!
 
-pytest is a mature Python testing tool with more than a 2000 tests
+pytest is a mature Python testing tool with more than 2000 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-4.5.0.rst

@@ -3,7 +3,7 @@ pytest-4.5.0
 
 The pytest team is proud to announce the 4.5.0 release!
 
-pytest is a mature Python testing tool with more than a 2000 tests
+pytest is a mature Python testing tool with more than 2000 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-4.6.0.rst

@@ -3,7 +3,7 @@ pytest-4.6.0
 
 The pytest team is proud to announce the 4.6.0 release!
 
-pytest is a mature Python testing tool with more than a 2000 tests
+pytest is a mature Python testing tool with more than 2000 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-5.0.0.rst

@@ -3,7 +3,7 @@ pytest-5.0.0
 
 The pytest team is proud to announce the 5.0.0 release!
 
-pytest is a mature Python testing tool with more than a 2000 tests
+pytest is a mature Python testing tool with more than 2000 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-5.1.0.rst

@@ -3,7 +3,7 @@ pytest-5.1.0
 
 The pytest team is proud to announce the 5.1.0 release!
 
-pytest is a mature Python testing tool with more than a 2000 tests
+pytest is a mature Python testing tool with more than 2000 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-5.2.0.rst

@@ -3,7 +3,7 @@ pytest-5.2.0
 
 The pytest team is proud to announce the 5.2.0 release!
 
-pytest is a mature Python testing tool with more than a 2000 tests
+pytest is a mature Python testing tool with more than 2000 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-5.3.0.rst

@@ -3,7 +3,7 @@ pytest-5.3.0
 
 The pytest team is proud to announce the 5.3.0 release!
 
-pytest is a mature Python testing tool with more than a 2000 tests
+pytest is a mature Python testing tool with more than 2000 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bugs fixes and improvements, so users are encouraged

doc/en/announce/release-5.4.0.rst

@@ -3,7 +3,7 @@ pytest-5.4.0
 
 The pytest team is proud to announce the 5.4.0 release!
 
-pytest is a mature Python testing tool with more than a 2000 tests
+pytest is a mature Python testing tool with more than 2000 tests
 against itself, passing on many different interpreters and platforms.
 
 This release contains a number of bug fixes and improvements, so users are encouraged

doc/en/announce/release-6.0.1.rst

@@ -0,0 +1,21 @@
+pytest-6.0.1
+=======================================
+
+pytest 6.0.1 has just been released to PyPI.
+
+This is a bug-fix release, being a drop-in replacement. To upgrade::
+
+  pip install --upgrade pytest
+
+The full changelog is available at https://docs.pytest.org/en/latest/changelog.html.
+
+Thanks to all who contributed to this release, among them:
+
+* Bruno Oliveira
+* Mattreex
+* Ran Benita
+* hp310780
+
+
+Happy testing,
+The pytest Development Team

doc/en/announce/release-6.0.2.rst

@@ -0,0 +1,19 @@
+pytest-6.0.2
+=======================================
+
+pytest 6.0.2 has just been released to PyPI.
+
+This is a bug-fix release, being a drop-in replacement. To upgrade::
+
+  pip install --upgrade pytest
+
+The full changelog is available at https://docs.pytest.org/en/stable/changelog.html.
+
+Thanks to all of the contributors to this release:
+
+* Bruno Oliveira
+* Ran Benita
+
+
+Happy testing,
+The pytest Development Team

doc/en/announce/release-6.1.0.rst

@@ -0,0 +1,44 @@
+pytest-6.1.0
+=======================================
+
+The pytest team is proud to announce the 6.1.0 release!
+
+This release contains new features, improvements, bug fixes, and breaking changes, so users
+are encouraged to take a look at the CHANGELOG carefully:
+
+    https://docs.pytest.org/en/stable/changelog.html
+
+For complete documentation, please visit:
+
+    https://docs.pytest.org/en/stable/
+
+As usual, you can upgrade from PyPI via:
+
+    pip install -U pytest
+
+Thanks to all of the contributors to this release:
+
+* Anthony Sottile
+* Bruno Oliveira
+* C. Titus Brown
+* Drew Devereux
+* Faris A Chugthai
+* Florian Bruhin
+* Hugo van Kemenade
+* Hynek Schlawack
+* Joseph Lucas
+* Kamran Ahmad
+* Mattreex
+* Maximilian Cosmo Sitter
+* Ran Benita
+* Rüdiger Busche
+* Sam Estep
+* Sorin Sbarnea
+* Thomas Grainger
+* Vipul Kumar
+* Yutaro Ikeda
+* hp310780
+
+
+Happy testing,
+The pytest Development Team

doc/en/announce/release-6.1.1.rst

@@ -0,0 +1,18 @@
+pytest-6.1.1
+=======================================
+
+pytest 6.1.1 has just been released to PyPI.
+
+This is a bug-fix release, being a drop-in replacement. To upgrade::
+
+  pip install --upgrade pytest
+
+The full changelog is available at https://docs.pytest.org/en/stable/changelog.html.
+
+Thanks to all of the contributors to this release:
+
+* Ran Benita
+
+
+Happy testing,
+The pytest Development Team

doc/en/announce/release-6.1.2.rst

@@ -0,0 +1,22 @@
+pytest-6.1.2
+=======================================
+
+pytest 6.1.2 has just been released to PyPI.
+
+This is a bug-fix release, being a drop-in replacement. To upgrade::
+
+  pip install --upgrade pytest
+
+The full changelog is available at https://docs.pytest.org/en/stable/changelog.html.
+
+Thanks to all of the contributors to this release:
+
+* Bruno Oliveira
+* Manuel Mariñez
+* Ran Benita
+* Vasilis Gerakaris
+* William Jamir Silva
+
+
+Happy testing,
+The pytest Development Team

doc/en/announce/release-6.2.0.rst

@@ -0,0 +1,76 @@
+pytest-6.2.0
+=======================================
+
+The pytest team is proud to announce the 6.2.0 release!
+
+This release contains new features, improvements, bug fixes, and breaking changes, so users
+are encouraged to take a look at the CHANGELOG carefully:
+
+    https://docs.pytest.org/en/stable/changelog.html
+
+For complete documentation, please visit:
+
+    https://docs.pytest.org/en/stable/
+
+As usual, you can upgrade from PyPI via:
+
+    pip install -U pytest
+
+Thanks to all of the contributors to this release:
+
+* Adam Johnson
+* Albert Villanova del Moral
+* Anthony Sottile
+* Anton
+* Ariel Pillemer
+* Bruno Oliveira
+* Charles Aracil
+* Christine M
+* Christine Mecklenborg
+* Cserna Zsolt
+* Dominic Mortlock
+* Emiel van de Laar
+* Florian Bruhin
+* Garvit Shubham
+* Gustavo Camargo
+* Hugo Martins
+* Hugo van Kemenade
+* Jakob van Santen
+* Josias Aurel
+* Jürgen Gmach
+* Karthikeyan Singaravelan
+* Katarzyna
+* Kyle Altendorf
+* Manuel Mariñez
+* Matthew Hughes
+* Matthias Gabriel
+* Max Voitko
+* Maximilian Cosmo Sitter
+* Mikhail Fesenko
+* Nimesh Vashistha
+* Pedro Algarvio
+* Petter Strandmark
+* Prakhar Gurunani
+* Prashant Sharma
+* Ran Benita
+* Ronny Pfannschmidt
+* Sanket Duthade
+* Shubham Adep
+* Simon K
+* Tanvi Mehta
+* Thomas Grainger
+* Tim Hoffmann
+* Vasilis Gerakaris
+* William Jamir Silva
+* Zac Hatfield-Dodds
+* crricks
+* dependabot[bot]
+* duthades
+* frankgerhardt
+* kwgchi
+* mickeypash
+* symonk
+
+
+Happy testing,
+The pytest Development Team

doc/en/assert.rst

@@ -74,7 +74,7 @@ Assertions about expected exceptions
 ------------------------------------------
 
 In order to write assertions about raised exceptions, you can use
-``pytest.raises`` as a context manager like this:
+:func:`pytest.raises` as a context manager like this:
 
 .. code-block:: python
 
@@ -123,7 +123,7 @@ The regexp parameter of the ``match`` method is matched with the ``re.search``
 function, so in the above example ``match='123'`` would have worked as
 well.
 
-There's an alternate form of the ``pytest.raises`` function where you pass
+There's an alternate form of the :func:`pytest.raises` function where you pass
 a function that will be executed with the given ``*args`` and ``**kwargs`` and
 assert that the given exception is raised:
 
@@ -144,8 +144,8 @@ specific way than just having any exception raised:
     def test_f():
         f()
 
-Using ``pytest.raises`` is likely to be better for cases where you are testing
-exceptions your own code is deliberately raising, whereas using
+Using :func:`pytest.raises` is likely to be better for cases where you are
+testing exceptions your own code is deliberately raising, whereas using
 ``@pytest.mark.xfail`` with a check function is probably better for something
 like documenting unfixed bugs (where the test describes what "should" happen)
 or bugs in dependencies.

doc/en/backwards-compatibility.rst

@@ -10,7 +10,7 @@ we keep learning about new and better structures to express different details ab
 
 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:
+As of now, pytest considers multiple types of backward compatibility transitions:
 
 a) trivial: APIs which trivially translate to the new mechanism,
    and do not cause problematic changes.
@@ -25,7 +25,7 @@ b) transitional: the old and new API don't conflict
    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.
+c) true breakage: should only 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:
@@ -42,7 +42,7 @@ c) true breakage: should only to be considered when normal transition is unreaso
 
    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.
+   This POC serves as both a coordination point to assess impact and potential inspiration 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.
 

doc/en/builtin.rst

@@ -23,7 +23,7 @@ For information about fixtures, see :ref:`fixtures`. To see a complete list of a
         cache.get(key, default)
         cache.set(key, value)
 
-        Keys must be a ``/`` separated value, where the first part is usually the
+        Keys must be ``/`` separated strings, where the first part is usually the
         name of your plugin or application to avoid clashes with other cache users.
 
         Values can be any object handled by the json stdlib module.
@@ -57,7 +57,8 @@ For information about fixtures, see :ref:`fixtures`. To see a complete list of a
         ``out`` and ``err`` will be ``byte`` objects.
 
     doctest_namespace [session scope]
-        Fixture that returns a :py:class:`dict` that will be injected into the namespace of doctests.
+        Fixture that returns a :py:class:`dict` that will be injected into the
+        namespace of doctests.
 
     pytestconfig [session scope]
         Session-scoped fixture that returns the :class:`_pytest.config.Config` object.
@@ -89,8 +90,10 @@ For information about fixtures, see :ref:`fixtures`. To see a complete list of a
         automatically XML-encoded.
 
     record_testsuite_property [session scope]
-        Records a new ``<property>`` tag as child of the root ``<testsuite>``. This is suitable to
-        writing global information regarding the entire test suite, and is compatible with ``xunit2`` JUnit family.
+        Record a new ``<property>`` tag as child of the root ``<testsuite>``.
+
+        This is suitable to writing global information regarding the entire test
+        suite, and is compatible with ``xunit2`` JUnit family.
 
         This is a ``session``-scoped fixture which is called with ``(name, value)``. Example:
 
@@ -102,6 +105,12 @@ For information about fixtures, see :ref:`fixtures`. To see a complete list of a
 
         ``name`` must be a string, ``value`` will be converted to a string and properly xml-escaped.
 
+        .. warning::
+
+            Currently this fixture **does not work** with the
+            `pytest-xdist <https://github.com/pytest-dev/pytest-xdist>`__ plugin. See issue
+            `#7767 <https://github.com/pytest-dev/pytest/issues/7767>`__ for details.
+
     caplog
         Access and control log capturing.
 
@@ -114,8 +123,10 @@ For information about fixtures, see :ref:`fixtures`. To see a complete list of a
         * caplog.clear()         -> clear captured records and formatted log output string
 
     monkeypatch
-        The returned ``monkeypatch`` fixture provides these
-        helper methods to modify objects, dictionaries or os.environ::
+        A convenient fixture for monkey-patching.
+
+        The fixture provides these methods to modify objects, dictionaries or
+        os.environ::
 
             monkeypatch.setattr(obj, name, value, raising=True)
             monkeypatch.delattr(obj, name, raising=True)
@@ -126,10 +137,9 @@ For information about fixtures, see :ref:`fixtures`. To see a complete list of a
             monkeypatch.syspath_prepend(path)
             monkeypatch.chdir(path)
 
-        All modifications will be undone after the requesting
-        test function or fixture has finished. The ``raising``
-        parameter determines if a KeyError or AttributeError
-        will be raised if the set/deletion operation has no target.
+        All modifications will be undone after the requesting test function or
+        fixture has finished. The ``raising`` parameter determines if a KeyError
+        or AttributeError will be raised if the set/deletion operation has no target.
 
     recwarn
         Return a :class:`WarningsRecorder` instance that records all warnings emitted by test functions.
@@ -140,30 +150,34 @@ For information about fixtures, see :ref:`fixtures`. To see a complete list of a
     tmpdir_factory [session scope]
         Return a :class:`_pytest.tmpdir.TempdirFactory` instance for the test session.
 
-
     tmp_path_factory [session scope]
         Return a :class:`_pytest.tmpdir.TempPathFactory` instance for the test session.
 
-
     tmpdir
-        Return a temporary directory path object
-        which is unique to each test function invocation,
-        created as a sub directory of the base temporary
-        directory.  The returned object is a `py.path.local`_
-        path object.
+        Return a temporary directory path object which is unique to each test
+        function invocation, created as a sub directory of the base temporary
+        directory.
+
+        By default, a new base temporary directory is created each test session,
+        and old bases are removed after 3 sessions, to aid in debugging. If
+        ``--basetemp`` is used then it is cleared each session. See :ref:`base
+        temporary directory`.
+
+        The returned object is a `py.path.local`_ path object.
 
         .. _`py.path.local`: https://py.readthedocs.io/en/latest/path.html
 
     tmp_path
-        Return a temporary directory path object
-        which is unique to each test function invocation,
-        created as a sub directory of the base temporary
-        directory.  The returned object is a :class:`pathlib.Path`
-        object.
+        Return a temporary directory path object which is unique to each test
+        function invocation, created as a sub directory of the base temporary
+        directory.
 
-        .. note::
+        By default, a new base temporary directory is created each test session,
+        and old bases are removed after 3 sessions, to aid in debugging. If
+        ``--basetemp`` is used then it is cleared each session. See :ref:`base
+        temporary directory`.
 
-            in python < 3.6 this is a pathlib2.Path
+        The returned object is a :class:`pathlib.Path` object.
 
 
     no tests ran in 0.12s

doc/en/cache.rst

@@ -264,7 +264,7 @@ the cache and nothing will be printed:
     FAILED test_caching.py::test_function - assert 42 == 23
     1 failed in 0.12s
 
-See the :fixture:`config.cache fixture <config.cache>` for more details.
+See the :fixture:`config.cache fixture <cache>` for more details.
 
 
 Inspecting Cache content

doc/en/changelog.rst

@@ -28,6 +28,433 @@ with advance notice in the **Deprecations** section of releases.
 
 .. towncrier release notes start
 
+pytest 6.2.0 (2020-12-12)
+=========================
+
+Breaking Changes
+----------------
+
+- `#7808 <https://github.com/pytest-dev/pytest/issues/7808>`_: pytest now supports python3.6+ only.
+
+
+
+Deprecations
+------------
+
+- `#7469 <https://github.com/pytest-dev/pytest/issues/7469>`_: Directly constructing/calling the following classes/functions is now deprecated:
+
+  - ``_pytest.cacheprovider.Cache``
+  - ``_pytest.cacheprovider.Cache.for_config()``
+  - ``_pytest.cacheprovider.Cache.clear_cache()``
+  - ``_pytest.cacheprovider.Cache.cache_dir_from_config()``
+  - ``_pytest.capture.CaptureFixture``
+  - ``_pytest.fixtures.FixtureRequest``
+  - ``_pytest.fixtures.SubRequest``
+  - ``_pytest.logging.LogCaptureFixture``
+  - ``_pytest.pytester.Pytester``
+  - ``_pytest.pytester.Testdir``
+  - ``_pytest.recwarn.WarningsRecorder``
+  - ``_pytest.recwarn.WarningsChecker``
+  - ``_pytest.tmpdir.TempPathFactory``
+  - ``_pytest.tmpdir.TempdirFactory``
+
+  These have always been considered private, but now issue a deprecation warning, which may become a hard error in pytest 7.0.0.
+
+
+- `#7530 <https://github.com/pytest-dev/pytest/issues/7530>`_: The ``--strict`` command-line option has been deprecated, use ``--strict-markers`` instead.
+
+  We have plans to maybe in the future to reintroduce ``--strict`` and make it an encompassing flag for all strictness
+  related options (``--strict-markers`` and ``--strict-config`` at the moment, more might be introduced in the future).
+
+
+- `#7988 <https://github.com/pytest-dev/pytest/issues/7988>`_: The ``@pytest.yield_fixture`` decorator/function is now deprecated. Use :func:`pytest.fixture` instead.
+
+  ``yield_fixture`` has been an alias for ``fixture`` for a very long time, so can be search/replaced safely.
+
+
+
+Features
+--------
+
+- `#5299 <https://github.com/pytest-dev/pytest/issues/5299>`_: pytest now warns about unraisable exceptions and unhandled thread exceptions that occur in tests on Python>=3.8.
+  See :ref:`unraisable` for more information.
+
+
+- `#7425 <https://github.com/pytest-dev/pytest/issues/7425>`_: New :fixture:`pytester` fixture, which is identical to :fixture:`testdir` but its methods return :class:`pathlib.Path` when appropriate instead of ``py.path.local``.
+
+  This is part of the movement to use :class:`pathlib.Path` objects internally, in order to remove the dependency to ``py`` in the future.
+
+  Internally, the old :class:`Testdir <_pytest.pytester.Testdir>` is now a thin wrapper around :class:`Pytester <_pytest.pytester.Pytester>`, preserving the old interface.
+
+
+- `#7695 <https://github.com/pytest-dev/pytest/issues/7695>`_: A new hook was added, `pytest_markeval_namespace` which should return a dictionary.
+  This dictionary will be used to augment the "global" variables available to evaluate skipif/xfail/xpass markers.
+
+  Pseudo example
+
+  ``conftest.py``:
+
+  .. code-block:: python
+
+     def pytest_markeval_namespace():
+         return {"color": "red"}
+
+  ``test_func.py``:
+
+  .. code-block:: python
+
+     @pytest.mark.skipif("color == 'blue'", reason="Color is not red")
+     def test_func():
+         assert False
+
+
+- `#8006 <https://github.com/pytest-dev/pytest/issues/8006>`_: It is now possible to construct a :class:`~pytest.MonkeyPatch` object directly as ``pytest.MonkeyPatch()``,
+  in cases when the :fixture:`monkeypatch` fixture cannot be used. Previously some users imported it
+  from the private `_pytest.monkeypatch.MonkeyPatch` namespace.
+
+  Additionally, :meth:`MonkeyPatch.context <pytest.MonkeyPatch.context>` is now a classmethod,
+  and can be used as ``with MonkeyPatch.context() as mp: ...``. This is the recommended way to use
+  ``MonkeyPatch`` directly, since unlike the ``monkeypatch`` fixture, an instance created directly
+  is not ``undo()``-ed automatically.
+
+
+
+Improvements
+------------
+
+- `#1265 <https://github.com/pytest-dev/pytest/issues/1265>`_: Added an ``__str__`` implementation to the :class:`~pytest.pytester.LineMatcher` class which is returned from ``pytester.run_pytest().stdout`` and similar. It returns the entire output, like the existing ``str()`` method.
+
+
+- `#2044 <https://github.com/pytest-dev/pytest/issues/2044>`_: Verbose mode now shows the reason that a test was skipped in the test's terminal line after the "SKIPPED", "XFAIL" or "XPASS".
+
+
+- `#7469 <https://github.com/pytest-dev/pytest/issues/7469>`_ The types of builtin pytest fixtures are now exported so they may be used in type annotations of test functions.
+  The newly-exported types are:
+
+  - ``pytest.FixtureRequest`` for the :fixture:`request` fixture.
+  - ``pytest.Cache`` for the :fixture:`cache` fixture.
+  - ``pytest.CaptureFixture[str]`` for the :fixture:`capfd` and :fixture:`capsys` fixtures.
+  - ``pytest.CaptureFixture[bytes]`` for the :fixture:`capfdbinary` and :fixture:`capsysbinary` fixtures.
+  - ``pytest.LogCaptureFixture`` for the :fixture:`caplog` fixture.
+  - ``pytest.Pytester`` for the :fixture:`pytester` fixture.
+  - ``pytest.Testdir`` for the :fixture:`testdir` fixture.
+  - ``pytest.TempdirFactory`` for the :fixture:`tmpdir_factory` fixture.
+  - ``pytest.TempPathFactory`` for the :fixture:`tmp_path_factory` fixture.
+  - ``pytest.MonkeyPatch`` for the :fixture:`monkeypatch` fixture.
+  - ``pytest.WarningsRecorder`` for the :fixture:`recwarn` fixture.
+
+  Constructing them is not supported (except for `MonkeyPatch`); they are only meant for use in type annotations.
+  Doing so will emit a deprecation warning, and may become a hard-error in pytest 7.0.
+
+  Subclassing them is also not supported. This is not currently enforced at runtime, but is detected by type-checkers such as mypy.
+
+
+- `#7527 <https://github.com/pytest-dev/pytest/issues/7527>`_: When a comparison between :func:`namedtuple <collections.namedtuple>` instances of the same type fails, pytest now shows the differing field names (possibly nested) instead of their indexes.
+
+
+- `#7615 <https://github.com/pytest-dev/pytest/issues/7615>`_: :meth:`Node.warn <_pytest.nodes.Node.warn>` now permits any subclass of :class:`Warning`, not just :class:`PytestWarning <pytest.PytestWarning>`.
+
+
+- `#7701 <https://github.com/pytest-dev/pytest/issues/7701>`_: Improved reporting when using ``--collected-only``. It will now show the number of collected tests in the summary stats.
+
+
+- `#7710 <https://github.com/pytest-dev/pytest/issues/7710>`_: Use strict equality comparison for non-numeric types in :func:`pytest.approx` instead of
+  raising :class:`TypeError`.
+
+  This was the undocumented behavior before 3.7, but is now officially a supported feature.
+
+
+- `#7938 <https://github.com/pytest-dev/pytest/issues/7938>`_: New ``--sw-skip`` argument which is a shorthand for ``--stepwise-skip``.
+
+
+- `#8023 <https://github.com/pytest-dev/pytest/issues/8023>`_: Added ``'node_modules'`` to default value for :confval:`norecursedirs`.
+
+
+- `#8032 <https://github.com/pytest-dev/pytest/issues/8032>`_: :meth:`doClassCleanups <unittest.TestCase.doClassCleanups>` (introduced in :mod:`unittest` in Python and 3.8) is now called appropriately.
+
+
+
+Bug Fixes
+---------
+
+- `#4824 <https://github.com/pytest-dev/pytest/issues/4824>`_: Fixed quadratic behavior and improved performance of collection of items using autouse fixtures and xunit fixtures.
+
+
+- `#7758 <https://github.com/pytest-dev/pytest/issues/7758>`_: Fixed an issue where some files in packages are getting lost from ``--lf`` even though they contain tests that failed. Regressed in pytest 5.4.0.
+
+
+- `#7911 <https://github.com/pytest-dev/pytest/issues/7911>`_: Directories created by by :fixture:`tmp_path` and :fixture:`tmpdir` are now considered stale after 3 days without modification (previous value was 3 hours) to avoid deleting directories still in use in long running test suites.
+
+
+- `#7913 <https://github.com/pytest-dev/pytest/issues/7913>`_: Fixed a crash or hang in :meth:`pytester.spawn <_pytest.pytester.Pytester.spawn>` when the :mod:`readline` module is involved.
+
+
+- `#7951 <https://github.com/pytest-dev/pytest/issues/7951>`_: Fixed handling of recursive symlinks when collecting tests.
+
+
+- `#7981 <https://github.com/pytest-dev/pytest/issues/7981>`_: Fixed symlinked directories not being followed during collection. Regressed in pytest 6.1.0.
+
+
+- `#8016 <https://github.com/pytest-dev/pytest/issues/8016>`_: Fixed only one doctest being collected when using ``pytest --doctest-modules path/to/an/__init__.py``.
+
+
+
+Improved Documentation
+----------------------
+
+- `#7429 <https://github.com/pytest-dev/pytest/issues/7429>`_: Add more information and use cases about skipping doctests.
+
+
+- `#7780 <https://github.com/pytest-dev/pytest/issues/7780>`_: Classes which should not be inherited from are now marked ``final class`` in the API reference.
+
+
+- `#7872 <https://github.com/pytest-dev/pytest/issues/7872>`_: ``_pytest.config.argparsing.Parser.addini()`` accepts explicit ``None`` and ``"string"``.
+
+
+- `#7878 <https://github.com/pytest-dev/pytest/issues/7878>`_: In pull request section, ask to commit after editing changelog and authors file.
+
+
+
+Trivial/Internal Changes
+------------------------
+
+- `#7802 <https://github.com/pytest-dev/pytest/issues/7802>`_: The ``attrs`` dependency requirement is now >=19.2.0 instead of >=17.4.0.
+
+
+- `#8014 <https://github.com/pytest-dev/pytest/issues/8014>`_: `.pyc` files created by pytest's assertion rewriting now conform to the newer PEP-552 format on Python>=3.7.
+  (These files are internal and only interpreted by pytest itself.)
+
+
+pytest 6.1.2 (2020-10-28)
+=========================
+
+Bug Fixes
+---------
+
+- `#7758 <https://github.com/pytest-dev/pytest/issues/7758>`_: Fixed an issue where some files in packages are getting lost from ``--lf`` even though they contain tests that failed. Regressed in pytest 5.4.0.
+
+
+- `#7911 <https://github.com/pytest-dev/pytest/issues/7911>`_: Directories created by `tmpdir` are now considered stale after 3 days without modification (previous value was 3 hours) to avoid deleting directories still in use in long running test suites.
+
+
+
+Improved Documentation
+----------------------
+
+- `#7815 <https://github.com/pytest-dev/pytest/issues/7815>`_: Improve deprecation warning message for ``pytest._fillfuncargs()``.
+
+
+pytest 6.1.1 (2020-10-03)
+=========================
+
+Bug Fixes
+---------
+
+- `#7807 <https://github.com/pytest-dev/pytest/issues/7807>`_: Fixed regression in pytest 6.1.0 causing incorrect rootdir to be determined in some non-trivial cases where parent directories have config files as well.
+
+
+- `#7814 <https://github.com/pytest-dev/pytest/issues/7814>`_: Fixed crash in header reporting when :confval:`testpaths` is used and contains absolute paths (regression in 6.1.0).
+
+
+pytest 6.1.0 (2020-09-26)
+=========================
+
+Breaking Changes
+----------------
+
+- `#5585 <https://github.com/pytest-dev/pytest/issues/5585>`_: As per our policy, the following features which have been deprecated in the 5.X series are now
+  removed:
+
+  * The ``funcargnames`` read-only property of ``FixtureRequest``, ``Metafunc``, and ``Function`` classes. Use ``fixturenames`` attribute.
+
+  * ``@pytest.fixture`` no longer supports positional arguments, pass all arguments by keyword instead.
+
+  * Direct construction of ``Node`` subclasses now raise an error, use ``from_parent`` instead.
+
+  * The default value for ``junit_family`` has changed to ``xunit2``. If you require the old format, add ``junit_family=xunit1`` to your configuration file.
+
+  * The ``TerminalReporter`` no longer has a ``writer`` attribute. Plugin authors may use the public functions of the ``TerminalReporter`` instead of accessing the ``TerminalWriter`` object directly.
+
+  * The ``--result-log`` option has been removed. Users are recommended to use the `pytest-reportlog <https://github.com/pytest-dev/pytest-reportlog>`__ plugin instead.
+
+
+  For more information consult
+  `Deprecations and Removals <https://docs.pytest.org/en/stable/deprecations.html>`__ in the docs.
+
+
+
+Deprecations
+------------
+
+- `#6981 <https://github.com/pytest-dev/pytest/issues/6981>`_: The ``pytest.collect`` module is deprecated: all its names can be imported from ``pytest`` directly.
+
+
+- `#7097 <https://github.com/pytest-dev/pytest/issues/7097>`_: The ``pytest._fillfuncargs`` function is deprecated. This function was kept
+  for backward compatibility with an older plugin.
+
+  It's functionality is not meant to be used directly, but if you must replace
+  it, use `function._request._fillfixtures()` instead, though note this is not
+  a public API and may break in the future.
+
+
+- `#7210 <https://github.com/pytest-dev/pytest/issues/7210>`_: The special ``-k '-expr'`` syntax to ``-k`` is deprecated. Use ``-k 'not expr'``
+  instead.
+
+  The special ``-k 'expr:'`` syntax to ``-k`` is deprecated. Please open an issue
+  if you use this and want a replacement.
+
+
+- `#7255 <https://github.com/pytest-dev/pytest/issues/7255>`_: The :func:`pytest_warning_captured <_pytest.hookspec.pytest_warning_captured>` hook is deprecated in favor
+  of :func:`pytest_warning_recorded <_pytest.hookspec.pytest_warning_recorded>`, and will be removed in a future version.
+
+
+- `#7648 <https://github.com/pytest-dev/pytest/issues/7648>`_: The ``gethookproxy()`` and ``isinitpath()`` methods of ``FSCollector`` and ``Package`` are deprecated;
+  use ``self.session.gethookproxy()`` and ``self.session.isinitpath()`` instead.
+  This should work on all pytest versions.
+
+
+
+Features
+--------
+
+- `#7667 <https://github.com/pytest-dev/pytest/issues/7667>`_: New ``--durations-min`` command-line flag controls the minimal duration for inclusion in the slowest list of tests shown by ``--durations``. Previously this was hard-coded to ``0.005s``.
+
+
+
+Improvements
+------------
+
+- `#6681 <https://github.com/pytest-dev/pytest/issues/6681>`_: Internal pytest warnings issued during the early stages of initialization are now properly handled and can filtered through :confval:`filterwarnings` or ``--pythonwarnings/-W``.
+
+  This also fixes a number of long standing issues: `#2891 <https://github.com/pytest-dev/pytest/issues/2891>`__, `#7620 <https://github.com/pytest-dev/pytest/issues/7620>`__, `#7426 <https://github.com/pytest-dev/pytest/issues/7426>`__.
+
+
+- `#7572 <https://github.com/pytest-dev/pytest/issues/7572>`_: When a plugin listed in ``required_plugins`` is missing or an unknown config key is used with ``--strict-config``, a simple error message is now shown instead of a stacktrace.
+
+
+- `#7685 <https://github.com/pytest-dev/pytest/issues/7685>`_: Added two new attributes :attr:`rootpath <_pytest.config.Config.rootpath>` and :attr:`inipath <_pytest.config.Config.inipath>` to :class:`Config <_pytest.config.Config>`.
+  These attributes are :class:`pathlib.Path` versions of the existing :attr:`rootdir <_pytest.config.Config.rootdir>` and :attr:`inifile <_pytest.config.Config.inifile>` attributes,
+  and should be preferred over them when possible.
+
+
+- `#7780 <https://github.com/pytest-dev/pytest/issues/7780>`_: Public classes which are not designed to be inherited from are now marked `@final <https://docs.python.org/3/library/typing.html#typing.final>`_.
+  Code which inherits from these classes will trigger a type-checking (e.g. mypy) error, but will still work in runtime.
+  Currently the ``final`` designation does not appear in the API Reference but hopefully will in the future.
+
+
+
+Bug Fixes
+---------
+
+- `#1953 <https://github.com/pytest-dev/pytest/issues/1953>`_: Fixed error when overwriting a parametrized fixture, while also reusing the super fixture value.
+
+  .. code-block:: python
+
+      # conftest.py
+      import pytest
+
+
+      @pytest.fixture(params=[1, 2])
+      def foo(request):
+          return request.param
+
+
+      # test_foo.py
+      import pytest
+
+
+      @pytest.fixture
+      def foo(foo):
+          return foo * 2
+
+
+- `#4984 <https://github.com/pytest-dev/pytest/issues/4984>`_: Fixed an internal error crash with ``IndexError: list index out of range`` when
+  collecting a module which starts with a decorated function, the decorator
+  raises, and assertion rewriting is enabled.
+
+
+- `#7591 <https://github.com/pytest-dev/pytest/issues/7591>`_: pylint shouldn't complain anymore about unimplemented abstract methods when inheriting from :ref:`File <non-python tests>`.
+
+
+- `#7628 <https://github.com/pytest-dev/pytest/issues/7628>`_: Fixed test collection when a full path without a drive letter was passed to pytest on Windows (for example ``\projects\tests\test.py`` instead of ``c:\projects\tests\pytest.py``).
+
+
+- `#7638 <https://github.com/pytest-dev/pytest/issues/7638>`_: Fix handling of command-line options that appear as paths but trigger an OS-level syntax error on Windows, such as the options used internally by ``pytest-xdist``.
+
+
+- `#7742 <https://github.com/pytest-dev/pytest/issues/7742>`_: Fixed INTERNALERROR when accessing locals / globals with faulty ``exec``.
+
+
+
+Improved Documentation
+----------------------
+
+- `#1477 <https://github.com/pytest-dev/pytest/issues/1477>`_: Removed faq.rst and its reference in contents.rst.
+
+
+
+Trivial/Internal Changes
+------------------------
+
+- `#7536 <https://github.com/pytest-dev/pytest/issues/7536>`_: The internal ``junitxml`` plugin has rewritten to use ``xml.etree.ElementTree``.
+  The order of attributes in XML elements might differ. Some unneeded escaping is
+  no longer performed.
+
+
+- `#7587 <https://github.com/pytest-dev/pytest/issues/7587>`_: The dependency on the ``more-itertools`` package has been removed.
+
+
+- `#7631 <https://github.com/pytest-dev/pytest/issues/7631>`_: The result type of :meth:`capfd.readouterr() <_pytest.capture.CaptureFixture.readouterr>` (and similar) is no longer a namedtuple,
+  but should behave like one in all respects. This was done for technical reasons.
+
+
+- `#7671 <https://github.com/pytest-dev/pytest/issues/7671>`_: When collecting tests, pytest finds test classes and functions by examining the
+  attributes of python objects (modules, classes and instances). To speed up this
+  process, pytest now ignores builtin attributes (like ``__class__``,
+  ``__delattr__`` and ``__new__``) without consulting the :confval:`python_classes` and
+  :confval:`python_functions` configuration options and without passing them to plugins
+  using the :func:`pytest_pycollect_makeitem <_pytest.hookspec.pytest_pycollect_makeitem>` hook.
+
+
+pytest 6.0.2 (2020-09-04)
+=========================
+
+Bug Fixes
+---------
+
+- `#7148 <https://github.com/pytest-dev/pytest/issues/7148>`_: Fixed ``--log-cli`` potentially causing unrelated ``print`` output to be swallowed.
+
+
+- `#7672 <https://github.com/pytest-dev/pytest/issues/7672>`_: Fixed log-capturing level restored incorrectly if ``caplog.set_level`` is called more than once.
+
+
+- `#7686 <https://github.com/pytest-dev/pytest/issues/7686>`_: Fixed `NotSetType.token` being used as the parameter ID when the parametrization list is empty.
+  Regressed in pytest 6.0.0.
+
+
+- `#7707 <https://github.com/pytest-dev/pytest/issues/7707>`_: Fix internal error when handling some exceptions that contain multiple lines or the style uses multiple lines (``--tb=line`` for example).
+
+
+pytest 6.0.1 (2020-07-30)
+=========================
+
+Bug Fixes
+---------
+
+- `#7394 <https://github.com/pytest-dev/pytest/issues/7394>`_: Passing an empty ``help`` value to ``Parser.add_option`` is now accepted instead of crashing when running ``pytest --help``.
+  Passing ``None`` raises a more informative ``TypeError``.
+
+
+- `#7558 <https://github.com/pytest-dev/pytest/issues/7558>`_: Fix pylint ``not-callable`` lint on ``pytest.mark.parametrize()`` and the other builtin marks:
+  ``skip``, ``skipif``, ``xfail``, ``usefixtures``, ``filterwarnings``.
+
+
+- `#7559 <https://github.com/pytest-dev/pytest/issues/7559>`_: Fix regression in plugins using ``TestReport.longreprtext`` (such as ``pytest-html``) when ``TestReport.longrepr`` is not a string.
+
+
+- `#7569 <https://github.com/pytest-dev/pytest/issues/7569>`_: Fix logging capture handler's level not reset on teardown after a call to ``caplog.set_level()``.
+
+
 pytest 6.0.0 (2020-07-28)
 =========================
 
@@ -192,9 +619,9 @@ Breaking Changes
 
 
 - `#7224 <https://github.com/pytest-dev/pytest/issues/7224>`_: The `item.catch_log_handler` and `item.catch_log_handlers` attributes, set by the
-  logging plugin and never meant to be public , are no longer available.
+  logging plugin and never meant to be public, are no longer available.
 
-  The deprecated ``--no-print-logs`` option is removed. Use ``--show-capture`` instead.
+  The deprecated ``--no-print-logs`` option and ``log_print`` ini option are removed. Use ``--show-capture`` instead.
 
 
 - `#7226 <https://github.com/pytest-dev/pytest/issues/7226>`_: Removed the unused ``args`` parameter from ``pytest.Function.__init__``.
@@ -1643,6 +2070,44 @@ Improved Documentation
 - `#5416 <https://github.com/pytest-dev/pytest/issues/5416>`_: Fix PytestUnknownMarkWarning in run/skip example.
 
 
+pytest 4.6.11 (2020-06-04)
+==========================
+
+Bug Fixes
+---------
+
+- `#6334 <https://github.com/pytest-dev/pytest/issues/6334>`_: Fix summary entries appearing twice when ``f/F`` and ``s/S`` report chars were used at the same time in the ``-r`` command-line option (for example ``-rFf``).
+
+  The upper case variants were never documented and the preferred form should be the lower case.
+
+
+- `#7310 <https://github.com/pytest-dev/pytest/issues/7310>`_: Fix ``UnboundLocalError: local variable 'letter' referenced before
+  assignment`` in ``_pytest.terminal.pytest_report_teststatus()``
+  when plugins return report objects in an unconventional state.
+
+  This was making ``pytest_report_teststatus()`` skip
+  entering if-block branches that declare the ``letter`` variable.
+
+  The fix was to set the initial value of the ``letter`` before
+  the if-block cascade so that it always has a value.
+
+
+pytest 4.6.10 (2020-05-08)
+==========================
+
+Features
+--------
+
+- `#6870 <https://github.com/pytest-dev/pytest/issues/6870>`_: New ``Config.invocation_args`` attribute containing the unchanged arguments passed to ``pytest.main()``.
+
+  Remark: while this is technically a new feature and according to our `policy <https://docs.pytest.org/en/latest/py27-py34-deprecation.html#what-goes-into-4-6-x-releases>`_ it should not have been backported, we have opened an exception in this particular case because it fixes a serious interaction with ``pytest-xdist``, so it can also be considered a bugfix.
+
+Trivial/Internal Changes
+------------------------
+
+- `#6404 <https://github.com/pytest-dev/pytest/issues/6404>`_: Remove usage of ``parser`` module, deprecated in Python 3.9.
+
+
 pytest 4.6.9 (2020-01-04)
 =========================
 
@@ -7383,7 +7848,7 @@ Bug fixes:
 - pluginmanager.register(...) now raises ValueError if the
   plugin has been already registered or the name is taken
 
-- fix issue159: improve http://pytest.org/en/stable/faq.html
+- fix issue159: improve https://docs.pytest.org/en/6.0.1/faq.html
   especially with respect to the "magic" history, also mention
   pytest-django, trial and unittest integration.
 

doc/en/conf.py

@@ -15,11 +15,13 @@
 #
 # The full version, including alpha/beta/rc tags.
 # The short X.Y version.
+import ast
 import os
 import sys
+from typing import List
+from typing import TYPE_CHECKING
 
 from _pytest import __version__ as version
-from _pytest.compat import TYPE_CHECKING
 
 if TYPE_CHECKING:
     import sphinx.application
@@ -398,3 +400,22 @@ def setup(app: "sphinx.application.Sphinx") -> None:
     )
 
     configure_logging(app)
+
+    # Make Sphinx mark classes with "final" when decorated with @final.
+    # We need this because we import final from pytest._compat, not from
+    # typing (for Python < 3.8 compat), so Sphinx doesn't detect it.
+    # To keep things simple we accept any `@final` decorator.
+    # Ref: https://github.com/pytest-dev/pytest/pull/7780
+    import sphinx.pycode.ast
+    import sphinx.pycode.parser
+
+    original_is_final = sphinx.pycode.parser.VariableCommentPicker.is_final
+
+    def patched_is_final(self, decorators: List[ast.expr]) -> bool:
+        if original_is_final(self, decorators):
+            return True
+        return any(
+            sphinx.pycode.ast.unparse(decorator) == "final" for decorator in decorators
+        )
+
+    sphinx.pycode.parser.VariableCommentPicker.is_final = patched_is_final

doc/en/contents.rst

@@ -38,7 +38,6 @@ Full pytest documentation
    customize
    example/index
    bash-completion
-   faq
 
    backwards-compatibility
    deprecations

doc/en/customize.rst

@@ -180,10 +180,15 @@ are never merged - the first match wins.
 The internal :class:`Config <_pytest.config.Config>` object (accessible via hooks or through the :fixture:`pytestconfig` fixture)
 will subsequently carry these attributes:
 
-- ``config.rootdir``: the determined root directory, guaranteed to exist.
+- :attr:`config.rootpath <_pytest.config.Config.rootpath>`: the determined root directory, guaranteed to exist.
 
-- ``config.inifile``: the determined ``configfile``, may be ``None`` (it is named ``inifile``
-  for historical reasons).
+- :attr:`config.inipath <_pytest.config.Config.inipath>`: the determined ``configfile``, may be ``None``
+  (it is named ``inipath`` for historical reasons).
+
+.. versionadded:: 6.1
+    The ``config.rootpath`` and ``config.inipath`` properties. They are :class:`pathlib.Path`
+    versions of the older ``config.rootdir`` and ``config.inifile``, which have type
+    ``py.path.local``, and still exist for backward compatibility.
 
 The ``rootdir`` is used as a reference directory for constructing test
 addresses ("nodeids") and can be used also by plugins for storing

doc/en/deprecations.rst

@@ -16,8 +16,29 @@ Deprecated Features
 -------------------
 
 Below is a complete list of all pytest features which are considered deprecated. Using those features will issue
-:class:`_pytest.warning_types.PytestWarning` or subclasses, which can be filtered using
-:ref:`standard warning filters <warnings>`.
+:class:`PytestWarning` or subclasses, which can be filtered using :ref:`standard warning filters <warnings>`.
+
+The ``--strict`` command-line option
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. deprecated:: 6.2
+
+The ``--strict`` command-line option has been deprecated in favor of ``--strict-markers``, which
+better conveys what the option does.
+
+We have plans to maybe in the future to reintroduce ``--strict`` and make it an encompassing
+flag for all strictness related options (``--strict-markers`` and ``--strict-config``
+at the moment, more might be introduced in the future).
+
+
+The ``yield_fixture`` function/decorator
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. deprecated:: 6.2
+
+``pytest.yield_fixture`` is a deprecated alias for :func:`pytest.fixture`.
+
+It has been so for a very long time, so can be search/replaced safely.
 
 
 The ``pytest_warning_captured`` hook
@@ -30,11 +51,19 @@ This hook has an `item` parameter which cannot be serialized by ``pytest-xdist``
 Use the ``pytest_warning_recored`` hook instead, which replaces the ``item`` parameter
 by a ``nodeid`` parameter.
 
+The ``pytest.collect`` module
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. deprecated:: 6.0
+
+The ``pytest.collect`` module is no longer part of the public API, all its names
+should now be imported from ``pytest`` directly instead.
+
 
 The ``pytest._fillfuncargs`` function
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. deprecated:: 5.5
+.. deprecated:: 6.0
 
 This function was kept for backward compatibility with an older plugin.
 
@@ -43,6 +72,11 @@ it, use `function._request._fillfixtures()` instead, though note this is not
 a public API and may break in the future.
 
 
+Removed Features
+----------------
+
+As stated in our :ref:`backwards-compatibility` policy, deprecated features are removed only in major releases after
+an appropriate period of deprecation has passed.
 
 ``--no-print-logs`` command-line option
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -51,45 +85,54 @@ a public API and may break in the future.
 .. versionremoved:: 6.0
 
 
-Option ``--no-print-logs`` is removed. If you used ``--no-print-logs``, please use ``--show-capture`` instead.
+The ``--no-print-logs`` option and ``log_print`` ini setting are removed. If
+you used them, please use ``--show-capture`` instead.
 
-``--show-capture`` command-line option was added in ``pytest 3.5.0`` and allows to specify how to
+A ``--show-capture`` command-line option was added in ``pytest 3.5.0`` which 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``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Result log (``--result-log``)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. deprecated:: 5.4
+.. deprecated:: 4.0
+.. versionremoved:: 6.0
 
-The construction of nodes now should use the named constructor ``from_parent``.
-This limitation in api surface intends to enable better/simpler refactoring of the collection tree.
+The ``--result-log`` option produces a stream of test reports which can be
+analysed at runtime, but it uses a custom format which requires users to implement their own
+parser.
 
-This means that instead of :code:`MyItem(name="foo", parent=collector, obj=42)`
-one now has to invoke :code:`MyItem.from_parent(collector, name="foo")`.
+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.
 
-Plugins that wish to support older versions of pytest and suppress the warning can use
-`hasattr` to check if `from_parent` exists in that version:
+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.
 
-.. code-block:: python
+``pytest_collect_directory`` hook
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-    def pytest_pycollect_makeitem(collector, name, obj):
-        if hasattr(MyItem, "from_parent"):
-            item = MyItem.from_parent(collector, name="foo")
-            item.obj = 42
-            return item
-        else:
-            return MyItem(name="foo", parent=collector, obj=42)
+.. versionremoved:: 6.0
 
-Note that ``from_parent`` should only be called with keyword arguments for the parameters.
+The ``pytest_collect_directory`` has not worked properly for years (it was called
+but the results were ignored). Users may consider using :func:`pytest_collection_modifyitems <_pytest.hookspec.pytest_collection_modifyitems>` instead.
 
+TerminalReporter.writer
+~~~~~~~~~~~~~~~~~~~~~~~
 
+.. versionremoved:: 6.0
+
+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``
+methods that provide the same functionality.
 
 ``junit_family`` default value change to "xunit2"
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. deprecated:: 5.2
+.. versionchanged:: 6.0
 
 The default value of ``junit_family`` option will change to ``xunit2`` in pytest 6.0, which
 is an update of the old ``xunit1`` format and is supported by default in modern tools
@@ -125,11 +168,44 @@ Services known to support the ``xunit2`` format:
 * `Jenkins <https://www.jenkins.io/>`__ with the `JUnit <https://plugins.jenkins.io/junit>`__ plugin.
 * `Azure Pipelines <https://azure.microsoft.com/en-us/services/devops/pipelines>`__.
 
+Node Construction changed to ``Node.from_parent``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. versionchanged:: 6.0
+
+The construction of nodes now should use the named constructor ``from_parent``.
+This limitation in api surface intends to enable better/simpler refactoring of the collection tree.
+
+This means that instead of :code:`MyItem(name="foo", parent=collector, obj=42)`
+one now has to invoke :code:`MyItem.from_parent(collector, name="foo")`.
+
+Plugins that wish to support older versions of pytest and suppress the warning can use
+`hasattr` to check if `from_parent` exists in that version:
+
+.. code-block:: python
+
+    def pytest_pycollect_makeitem(collector, name, obj):
+        if hasattr(MyItem, "from_parent"):
+            item = MyItem.from_parent(collector, name="foo")
+            item.obj = 42
+            return item
+        else:
+            return MyItem(name="foo", parent=collector, obj=42)
+
+Note that ``from_parent`` should only be called with keyword arguments for the parameters.
+
+
+``pytest.fixture`` arguments are keyword only
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. versionremoved:: 6.0
+
+Passing arguments to pytest.fixture() as positional arguments has been removed - pass them by keyword instead.
 
 ``funcargnames`` alias for ``fixturenames``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. deprecated:: 5.0
+.. versionremoved:: 6.0
 
 The ``FixtureRequest``, ``Metafunc``, and ``Function`` classes track the names of
 their associated fixtures, with the aptly-named ``fixturenames`` attribute.
@@ -140,42 +216,6 @@ in places where we or plugin authors must distinguish between fixture names and
 names supplied by non-fixture things such as ``pytest.mark.parametrize``.
 
 
-Result log (``--result-log``)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-.. deprecated:: 4.0
-
-The ``--result-log`` option produces a stream of test reports which can be
-analysed at runtime, but it uses a custom format which requires users to implement their own
-parser.
-
-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 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``
-methods that provide the same functionality.
-
-
-Removed Features
-----------------
-
-As stated in our :ref:`backwards-compatibility` policy, deprecated features are removed only in major releases after
-an appropriate period of deprecation has passed.
-
-
 ``pytest.config`` global
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -357,7 +397,7 @@ Metafunc.addcall
 
 .. versionremoved:: 4.0
 
-:meth:`_pytest.python.Metafunc.addcall` was a precursor to the current parametrized mechanism. Users should use
+``_pytest.python.Metafunc.addcall`` was a precursor to the current parametrized mechanism. Users should use
 :meth:`_pytest.python.Metafunc.parametrize` instead.
 
 Example:
@@ -592,7 +632,7 @@ This has been documented as deprecated for years, but only now we are actually e
 
 .. versionremoved:: 4.0
 
-As part of a large :ref:`marker-revamp`, :meth:`_pytest.nodes.Node.get_marker` is deprecated. See
+As part of a large :ref:`marker-revamp`, ``_pytest.nodes.Node.get_marker`` is removed. See
 :ref:`the documentation <update marker code>` on tips on how to update your code.
 
 

doc/en/doctest.rst

@@ -2,7 +2,7 @@
 Doctest integration for modules and test files
 =========================================================
 
-By default all files matching the ``test*.txt`` pattern will
+By default, all files matching the ``test*.txt`` pattern will
 be run through the python standard ``doctest`` module.  You
 can change the pattern by issuing:
 
@@ -77,15 +77,6 @@ putting them into a pytest.ini file like this:
     [pytest]
     addopts = --doctest-modules
 
-.. note::
-
-    The builtin pytest doctest supports only ``doctest`` blocks, but if you are looking
-    for more advanced checking over *all* your documentation,
-    including doctests, ``.. codeblock:: python`` Sphinx directive support,
-    and any other examples your documentation may include, you may wish to
-    consider `Sybil <https://sybil.readthedocs.io/en/latest/index.html>`__.
-    It provides pytest integration out of the box.
-
 
 Encoding
 --------
@@ -113,7 +104,7 @@ lengthy exception stack traces you can just write:
 .. code-block:: ini
 
     [pytest]
-    doctest_optionflags= NORMALIZE_WHITESPACE IGNORE_EXCEPTION_DETAIL
+    doctest_optionflags = NORMALIZE_WHITESPACE IGNORE_EXCEPTION_DETAIL
 
 Alternatively, options can be enabled by an inline comment in the doc test
 itself:
@@ -206,7 +197,7 @@ It is possible to use fixtures using the ``getfixture`` helper:
     >>> ...
     >>>
 
-Note that the fixture needs to be defined in a place visible by pytest, for example a `conftest.py`
+Note that the fixture needs to be defined in a place visible by pytest, for example, a `conftest.py`
 file or plugin; normal python files containing docstrings are not normally scanned for fixtures
 unless explicitly configured by :confval:`python_files`.
 
@@ -253,12 +244,32 @@ Note that like the normal ``conftest.py``, the fixtures are discovered in the di
 Meaning that if you put your doctest with your source code, the relevant conftest.py needs to be in the same directory tree.
 Fixtures will not be discovered in a sibling directory tree!
 
-Skipping tests dynamically
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+Skipping tests
+^^^^^^^^^^^^^^
 
-.. versionadded:: 4.4
+For the same reasons one might want to skip normal tests, it is also possible to skip
+tests inside doctests.
+
+To skip a single check inside a doctest you can use the standard
+`doctest.SKIP <https://docs.python.org/3/library/doctest.html#doctest.SKIP>`__ directive:
+
+.. code-block:: python
+
+    def test_random(y):
+        """
+        >>> random.random()  # doctest: +SKIP
+        0.156231223
+
+        >>> 1 + 1
+        2
+        """
+
+This will skip the first check, but not the second.
+
+pytest also allows using the standard pytest functions :func:`pytest.skip` and
+:func:`pytest.xfail` inside doctests, which might be useful because you can
+then skip/xfail tests based on external conditions:
 
-You can use ``pytest.skip`` to dynamically skip doctests. For example:
 
 .. code-block:: text
 
@@ -266,3 +277,35 @@ You can use ``pytest.skip`` to dynamically skip doctests. For example:
     >>> if sys.platform.startswith('win'):
     ...     pytest.skip('this doctest does not work on Windows')
     ...
+    >>> import fcntl
+    >>> ...
+
+However using those functions is discouraged because it reduces the readability of the
+docstring.
+
+.. note::
+
+    :func:`pytest.skip` and :func:`pytest.xfail` behave differently depending
+    if the doctests are in a Python file (in docstrings) or a text file containing
+    doctests intermingled with text:
+
+    * Python modules (docstrings): the functions only act in that specific docstring,
+      letting the other docstrings in the same module execute as normal.
+
+    * Text files: the functions will skip/xfail the checks for the rest of the entire
+      file.
+
+
+Alternatives
+------------
+
+While the built-in pytest support provides a good set of functionalities for using
+doctests, if you use them extensively you might be interested in those external packages
+which add many more features, and include pytest integration:
+
+* `pytest-doctestplus <https://github.com/astropy/pytest-doctestplus>`__: provides
+  advanced doctest support and enables the testing of reStructuredText (".rst") files.
+
+* `Sybil <https://sybil.readthedocs.io>`__: provides a way to test examples in
+  your documentation by parsing them from the documentation source and evaluating
+  the parsed examples as part of your normal test run.

doc/en/example/assertion/failure_demo.py

@@ -176,7 +176,7 @@ class TestRaises:
 
     def test_reinterpret_fails_with_print_for_the_fun_of_it(self):
         items = [1, 2, 3]
-        print("items is {!r}".format(items))
+        print(f"items is {items!r}")
         a, b = items.pop()
 
     def test_some_error(self):

doc/en/example/assertion/global_testmodule_config/conftest.py

@@ -11,4 +11,4 @@ def pytest_runtest_setup(item):
             return
         mod = item.getparent(pytest.Module).obj
         if hasattr(mod, "hello"):
-            print("mod.hello {!r}".format(mod.hello))
+            print(f"mod.hello {mod.hello!r}")

doc/en/example/markers.rst

@@ -201,6 +201,11 @@ Or to select "http" and "quick" tests:
 You can use ``and``, ``or``, ``not`` and parentheses.
 
 
+In addition to the test's name, ``-k`` also matches the names of the test's parents (usually, the name of the file and class it's in),
+attributes set on the test function, markers applied to it or its parents and any :attr:`extra keywords <_pytest.nodes.Node.extra_keyword_matches>`
+explicitly added to it or its parents.
+
+
 Registering markers
 -------------------------------------
 
@@ -216,14 +221,19 @@ Registering markers for your test suite is simple:
     [pytest]
     markers =
         webtest: mark a test as a webtest.
+        slow: mark test as slow.
 
-You can ask which markers exist for your test suite - the list includes our just defined ``webtest`` markers:
+Multiple custom markers can be registered, by defining each one in its own line, as shown in above example.
+
+You can ask which markers exist for your test suite - the list includes our just defined ``webtest`` and ``slow`` markers:
 
 .. code-block:: pytest
 
     $ pytest --markers
     @pytest.mark.webtest: mark a test as a webtest.
 
+    @pytest.mark.slow: mark test as slow.
+
     @pytest.mark.filterwarnings(warning): add a warning filter to the given test. see https://docs.pytest.org/en/stable/warnings.html#pytest-mark-filterwarnings
 
     @pytest.mark.skip(reason=None): skip the given test function with an optional reason. Example: skip(reason="no way of currently testing this") skips the test.
@@ -280,7 +290,7 @@ its test methods:
 This is equivalent to directly applying the decorator to the
 two test functions.
 
-To apply marks at the module level, use the :globalvar:`pytestmark` global variable:
+To apply marks at the module level, use the :globalvar:`pytestmark` global variable::
 
     import pytest
     pytestmark = pytest.mark.webtest
@@ -534,7 +544,7 @@ Let's run this without capturing output and see what we get:
     .
     1 passed in 0.12s
 
-marking platform specific tests with pytest
+Marking platform specific tests with pytest
 --------------------------------------------------------------
 
 .. regendoc:wipe

doc/en/example/multipython.py

@@ -26,7 +26,7 @@ class Python:
     def __init__(self, version, picklefile):
         self.pythonpath = shutil.which(version)
         if not self.pythonpath:
-            pytest.skip("{!r} not found".format(version))
+            pytest.skip(f"{version!r} not found")
         self.picklefile = picklefile
 
     def dumps(self, obj):
@@ -69,4 +69,4 @@ class Python:
 @pytest.mark.parametrize("obj", [42, {}, {1: 3}])
 def test_basic_objects(python1, python2, obj):
     python1.dumps(obj)
-    python2.load_and_is_true("obj == {}".format(obj))
+    python2.load_and_is_true(f"obj == {obj}")

doc/en/example/nonpython.rst

@@ -12,7 +12,7 @@ A basic example for specifying tests in Yaml files
 .. _`pytest-yamlwsgi`: http://bitbucket.org/aafshar/pytest-yamlwsgi/src/tip/pytest_yamlwsgi.py
 .. _`PyYAML`: https://pypi.org/project/PyYAML/
 
-Here is an example ``conftest.py`` (extracted from Ali Afshnars special purpose `pytest-yamlwsgi`_ plugin).   This ``conftest.py`` will  collect ``test*.yaml`` files and will execute the yaml-formatted content as custom tests:
+Here is an example ``conftest.py`` (extracted from Ali Afshar's special purpose `pytest-yamlwsgi`_ plugin).   This ``conftest.py`` will  collect ``test*.yaml`` files and will execute the yaml-formatted content as custom tests:
 
 .. include:: nonpython/conftest.py
     :literal:
@@ -102,4 +102,4 @@ interesting to just look at the collection tree:
         <YamlItem hello>
         <YamlItem ok>
 
-    ========================== no tests ran in 0.12s ===========================
+    ======================== 2 tests collected in 0.12s ========================

doc/en/example/nonpython/conftest.py

@@ -9,7 +9,8 @@ def pytest_collect_file(parent, path):
 
 class YamlFile(pytest.File):
     def collect(self):
-        import yaml  # we need a yaml parser, e.g. PyYAML
+        # We need a yaml parser, e.g. PyYAML.
+        import yaml
 
         raw = yaml.safe_load(self.fspath.open())
         for name, spec in sorted(raw.items()):
@@ -23,12 +24,12 @@ class YamlItem(pytest.Item):
 
     def runtest(self):
         for name, value in sorted(self.spec.items()):
-            # some custom test execution (dumb example follows)
+            # Some custom test execution (dumb example follows).
             if name != value:
                 raise YamlException(self, name, value)
 
     def repr_failure(self, excinfo):
-        """ called when self.runtest() raises an exception. """
+        """Called when self.runtest() raises an exception."""
         if isinstance(excinfo.value, YamlException):
             return "\n".join(
                 [
@@ -39,8 +40,8 @@ class YamlItem(pytest.Item):
             )
 
     def reportinfo(self):
-        return self.fspath, 0, "usecase: {}".format(self.name)
+        return self.fspath, 0, f"usecase: {self.name}"
 
 
 class YamlException(Exception):
-    """ custom exception for error reporting. """
+    """Custom exception for error reporting."""

doc/en/example/parametrize.rst

@@ -175,7 +175,7 @@ objects, they are still using the default pytest representation:
       <Function test_timedistance_v3[forward]>
       <Function test_timedistance_v3[backward]>
 
-    ========================== no tests ran in 0.12s ===========================
+    ======================== 8 tests collected in 0.12s ========================
 
 In ``test_timedistance_v3``, we used ``pytest.param`` to specify the test IDs
 together with the actual data, instead of listing them separately.
@@ -252,7 +252,7 @@ If you just collect tests you'll also nicely see 'advanced' and 'basic' as varia
           <Function test_demo1[advanced]>
           <Function test_demo2[advanced]>
 
-    ========================== no tests ran in 0.12s ===========================
+    ======================== 4 tests collected in 0.12s ========================
 
 Note that we told ``metafunc.parametrize()`` that your scenario values
 should be considered class-scoped.  With pytest-2.3 this leads to a
@@ -328,7 +328,7 @@ Let's first see how it looks like at collection time:
       <Function test_db_initialized[d1]>
       <Function test_db_initialized[d2]>
 
-    ========================== no tests ran in 0.12s ===========================
+    ======================== 2 tests collected in 0.12s ========================
 
 And then when we run the test:
 

doc/en/example/pythoncollection.rst

@@ -157,7 +157,7 @@ The test collection would look like this:
           <Function simple_check>
           <Function complex_check>
 
-    ========================== no tests ran in 0.12s ===========================
+    ======================== 2 tests collected in 0.12s ========================
 
 You can check for multiple glob patterns by adding a space between the patterns:
 
@@ -220,7 +220,7 @@ You can always peek at the collection tree without running tests like this:
           <Function test_method>
           <Function test_anothermethod>
 
-    ========================== no tests ran in 0.12s ===========================
+    ======================== 3 tests collected in 0.12s ========================
 
 .. _customizing-test-collection:
 
@@ -282,7 +282,7 @@ leave out the ``setup.py`` file:
     <Module 'pkg/module_py2.py'>
       <Function 'test_only_on_python2'>
 
-    ====== no tests ran in 0.04 seconds ======
+    ====== 1 tests found in 0.04 seconds ======
 
 If you run with a Python 3 interpreter both the one test and the ``setup.py``
 file will be left out:
@@ -296,7 +296,7 @@ file will be left out:
     rootdir: $REGENDOC_TMPDIR, configfile: pytest.ini
     collected 0 items
 
-    ========================== no tests ran in 0.12s ===========================
+    ======================= no tests collected in 0.12s ========================
 
 It's also possible to ignore files based on Unix shell-style wildcards by adding
 patterns to :globalvar:`collect_ignore_glob`.
@@ -313,3 +313,12 @@ interpreter:
     collect_ignore = ["setup.py"]
     if sys.version_info[0] > 2:
         collect_ignore_glob = ["*_py2.py"]
+
+Since Pytest 2.6, users can prevent pytest from discovering classes that start
+with ``Test`` by setting a boolean ``__test__`` attribute to ``False``.
+
+.. code-block:: python
+
+    # Will not be discovered as a test
+    class TestClass:
+        __test__ = False

doc/en/example/reportingdemo.rst

@@ -446,7 +446,7 @@ Here is a nice run of several failures and how ``pytest`` presents things:
 
         def test_reinterpret_fails_with_print_for_the_fun_of_it(self):
             items = [1, 2, 3]
-            print("items is {!r}".format(items))
+            print(f"items is {items!r}")
     >       a, b = items.pop()
     E       TypeError: cannot unpack non-iterable int object
 

doc/en/example/simple.rst

@@ -452,7 +452,7 @@ and nothing when run plainly:
 
     ========================== no tests ran in 0.12s ===========================
 
-profiling test duration
+Profiling test duration
 --------------------------
 
 .. regendoc:wipe
@@ -498,7 +498,7 @@ Now we can profile which test functions execute the slowest:
     0.10s call     test_some_are_slow.py::test_funcfast
     ============================ 3 passed in 0.12s =============================
 
-incremental testing - test steps
+Incremental testing - test steps
 ---------------------------------------------------
 
 .. regendoc:wipe
@@ -739,7 +739,7 @@ it (unless you use "autouse" fixture which are always executed ahead of the firs
 executing).
 
 
-post-process test reports / failures
+Post-process test reports / failures
 ---------------------------------------
 
 If you want to postprocess test reports and need access to the executing

doc/en/faq.rst

@@ -1,158 +0,0 @@
-Some Issues and Questions
-==================================
-
-.. note::
-
-    This FAQ is here only mostly for historic reasons.  Checkout
-    `pytest Q&A at Stackoverflow <http://stackoverflow.com/search?q=pytest>`_
-    for many questions and answers related to pytest and/or use
-    :ref:`contact channels` to get help.
-
-On naming, nosetests, licensing and magic
-------------------------------------------------
-
-How does pytest relate to nose and unittest?
-+++++++++++++++++++++++++++++++++++++++++++++++++
-
-``pytest`` and nose_ share basic philosophy when it comes
-to running and writing Python tests.  In fact, you can run many tests
-written for nose with ``pytest``.  nose_ was originally created
-as a clone of ``pytest`` when ``pytest`` was in the ``0.8`` release
-cycle.  Note that starting with pytest-2.0 support for running unittest
-test suites is majorly improved.
-
-how does pytest relate to twisted's trial?
-++++++++++++++++++++++++++++++++++++++++++++++
-
-Since some time ``pytest`` has builtin support for supporting tests
-written using trial. It does not itself start a reactor, however,
-and does not handle Deferreds returned from a test in pytest style.
-If you are using trial's unittest.TestCase chances are that you can
-just run your tests even if you return Deferreds.  In addition,
-there also is a dedicated `pytest-twisted
-<https://pypi.org/project/pytest-twisted/>`_ plugin which allows you to
-return deferreds from pytest-style tests, allowing the use of
-:ref:`fixtures <fixtures>` and other features.
-
-how does pytest work with Django?
-++++++++++++++++++++++++++++++++++++++++++++++
-
-In 2012, some work is going into the `pytest-django plugin <https://pypi.org/project/pytest-django/>`_.  It substitutes the usage of Django's
-``manage.py test`` and allows the use of all pytest features_ most of which
-are not available from Django directly.
-
-.. _features: features.html
-
-
-What's this "magic" with pytest? (historic notes)
-++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-
-Around 2007 (version ``0.8``) some people thought that ``pytest``
-was using too much "magic".  It had been part of the `pylib`_ which
-contains a lot of unrelated python library code.  Around 2010 there
-was a major cleanup refactoring, which removed unused or deprecated code
-and resulted in the new ``pytest`` PyPI package which strictly contains
-only test-related code.  This release also brought a complete pluginification
-such that the core is around 300 lines of code and everything else is
-implemented in plugins.  Thus ``pytest`` today is a small, universally runnable
-and customizable testing framework for Python.   Note, however, that
-``pytest`` uses metaprogramming techniques and reading its source is
-thus likely not something for Python beginners.
-
-A second "magic" issue was the assert statement debugging feature.
-Nowadays, ``pytest`` explicitly rewrites assert statements in test modules
-in order to provide more useful :ref:`assert feedback <assertfeedback>`.
-This completely avoids previous issues of confusing assertion-reporting.
-It also means, that you can use Python's ``-O`` optimization without losing
-assertions in test modules.
-
-You can also turn off all assertion interaction using the
-``--assert=plain`` option.
-
-.. _`py namespaces`: index.html
-.. _`py/__init__.py`: http://bitbucket.org/hpk42/py-trunk/src/trunk/py/__init__.py
-
-
-Why can I use both ``pytest`` and ``py.test`` commands?
-+++++++++++++++++++++++++++++++++++++++++++++++++++++++
-
-pytest used to be part of the py package, which provided several developer
-utilities, all starting with ``py.<TAB>``, thus providing nice TAB-completion.
-If you install ``pip install pycmd`` you get these tools from a separate
-package. Once ``pytest`` became a separate package, the ``py.test`` name was
-retained due to avoid a naming conflict with another tool. This conflict was
-eventually resolved, and the ``pytest`` command was therefore introduced. In
-future versions of pytest, we may deprecate and later remove the ``py.test``
-command to avoid perpetuating the confusion.
-
-pytest fixtures, parametrized tests
--------------------------------------------------------
-
-.. _funcargs: funcargs.html
-
-Is using pytest fixtures versus xUnit setup a style question?
-+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-
-For simple applications and for people experienced with nose_ or
-unittest-style test setup using `xUnit style setup`_ probably
-feels natural.  For larger test suites, parametrized testing
-or setup of complex test resources using fixtures_ may feel more natural.
-Moreover, fixtures are ideal for writing advanced test support
-code (like e.g. the monkeypatch_, the tmpdir_ or capture_ fixtures)
-because the support code can register setup/teardown functions
-in a managed class/module/function scope.
-
-.. _monkeypatch: monkeypatch.html
-.. _tmpdir: tmpdir.html
-.. _capture: capture.html
-.. _fixtures: fixture.html
-
-.. _`why pytest_pyfuncarg__ methods?`:
-
-.. _`Convention over Configuration`: http://en.wikipedia.org/wiki/Convention_over_Configuration
-
-Can I yield multiple values from a fixture function?
-++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-
-There are two conceptual reasons why yielding from a factory function
-is not possible:
-
-* If multiple factories yielded values there would
-  be no natural place to determine the combination
-  policy - in real-world examples some combinations
-  often should not run.
-
-* Calling factories for obtaining test function arguments
-  is part of setting up and running a test.  At that
-  point it is not possible to add new test calls to
-  the test collection anymore.
-
-However, with pytest-2.3 you can use the :ref:`@pytest.fixture` decorator
-and specify ``params`` so that all tests depending on the factory-created
-resource will run multiple times with different parameters.
-
-You can also use the ``pytest_generate_tests`` hook to
-implement the `parametrization scheme of your choice`_. See also
-:ref:`paramexamples` for more examples.
-
-.. _`parametrization scheme of your choice`: http://tetamap.wordpress.com/2009/05/13/parametrizing-python-tests-generalized/
-
-pytest interaction with other packages
----------------------------------------------------
-
-Issues with pytest, multiprocess and setuptools?
-+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-
-On Windows the multiprocess package will instantiate sub processes
-by pickling and thus implicitly re-import a lot of local modules.
-Unfortunately, setuptools-0.6.11 does not ``if __name__=='__main__'``
-protect its generated command line script.  This leads to infinite
-recursion when running a test that instantiates Processes.
-
-As of mid-2013, there shouldn't be a problem anymore when you
-use the standard setuptools (note that distribute has been merged
-back into setuptools which is now shipped directly with virtualenv).
-
-.. _nose: https://nose.readthedocs.io/en/latest/
-.. _pylib: https://py.readthedocs.io/en/latest/
-.. _`xUnit style setup`: xunit_setup.html

doc/en/fixture.rst

@@ -121,7 +121,7 @@ Fixtures as Function arguments
 Test functions can receive fixture objects by naming them as an input
 argument. For each argument name, a fixture function with that name provides
 the fixture object.  Fixture functions are registered by marking them with
-:py:func:`@pytest.fixture <_pytest.python.fixture>`.  Let's look at a simple
+:py:func:`@pytest.fixture <pytest.fixture>`.  Let's look at a simple
 self-contained test module containing a fixture and a test function
 using it:
 
@@ -144,7 +144,7 @@ using it:
         assert 0  # for demo purposes
 
 Here, the ``test_ehlo`` needs the ``smtp_connection`` fixture value.  pytest
-will discover and call the :py:func:`@pytest.fixture <_pytest.python.fixture>`
+will discover and call the :py:func:`@pytest.fixture <pytest.fixture>`
 marked ``smtp_connection`` fixture function.  Running the test looks like this:
 
 .. code-block:: pytest
@@ -252,7 +252,7 @@ Scope: sharing fixtures across classes, modules, packages or session
 Fixtures requiring network access depend on connectivity and are
 usually time-expensive to create.  Extending the previous example, we
 can add a ``scope="module"`` parameter to the
-:py:func:`@pytest.fixture <_pytest.python.fixture>` invocation
+:py:func:`@pytest.fixture <pytest.fixture>` invocation
 to cause the decorated ``smtp_connection`` fixture function to only be invoked
 once per test *module* (the default is to invoke once per test *function*).
 Multiple test functions in a test module will thus
@@ -592,7 +592,7 @@ will not be executed.
 Fixtures can introspect the requesting test context
 -------------------------------------------------------------
 
-Fixture functions can accept the :py:class:`request <FixtureRequest>` object
+Fixture functions can accept the :py:class:`request <_pytest.fixtures.FixtureRequest>` object
 to introspect the "requesting" test function, class or module context.
 Further extending the previous ``smtp_connection`` fixture example, let's
 read an optional server URL from the test module which uses our fixture:
@@ -664,7 +664,7 @@ from the module namespace.
 Using markers to pass data to fixtures
 -------------------------------------------------------------
 
-Using the :py:class:`request <FixtureRequest>` object, a fixture can also access
+Using the :py:class:`request <_pytest.fixtures.FixtureRequest>` object, a fixture can also access
 markers which are applied to a test function. This can be useful to pass data
 into a fixture from a test:
 
@@ -775,7 +775,7 @@ through the special :py:class:`request <FixtureRequest>` object:
         smtp_connection.close()
 
 The main change is the declaration of ``params`` with
-:py:func:`@pytest.fixture <_pytest.python.fixture>`, a list of values
+:py:func:`@pytest.fixture <pytest.fixture>`, a list of values
 for each of which the fixture function will execute and can access
 a value via ``request.param``.  No test function code needs to change.
 So let's just do another run:
@@ -919,7 +919,7 @@ Running the above tests results in the following test IDs being used:
      <Function test_ehlo[mail.python.org]>
      <Function test_noop[mail.python.org]>
 
-   ========================== no tests ran in 0.12s ===========================
+   ======================= 10 tests collected in 0.12s ========================
 
 .. _`fixture-parametrize-marks`:
 
@@ -947,7 +947,7 @@ Example:
 
 Running this test will *skip* the invocation of ``data_set`` with value ``2``:
 
-.. code-block:: pytest
+.. code-block::
 
     $ pytest test_fixture_marks.py -v
     =========================== test session starts ============================
@@ -958,7 +958,7 @@ Running this test will *skip* the invocation of ``data_set`` with value ``2``:
 
     test_fixture_marks.py::test_data[0] PASSED                           [ 33%]
     test_fixture_marks.py::test_data[1] PASSED                           [ 66%]
-    test_fixture_marks.py::test_data[2] SKIPPED                          [100%]
+    test_fixture_marks.py::test_data[2] SKIPPED (unconditional skip)     [100%]
 
     ======================= 2 passed, 1 skipped in 0.12s =======================
 
@@ -1136,8 +1136,8 @@ and teared down after every test that used it.
 
 .. _`usefixtures`:
 
-Using fixtures from classes, modules or projects
-----------------------------------------------------------------------
+Use fixtures in classes and modules with ``usefixtures``
+--------------------------------------------------------
 
 .. regendoc:wipe
 
@@ -1531,3 +1531,37 @@ Given the tests file structure is:
 In the example above, a parametrized fixture is overridden with a non-parametrized version, and
 a non-parametrized fixture is overridden with a parametrized version for certain test module.
 The same applies for the test folder level obviously.
+
+
+Using fixtures from other projects
+----------------------------------
+
+Usually projects that provide pytest support will use :ref:`entry points <setuptools entry points>`,
+so just installing those projects into an environment will make those fixtures available for use.
+
+In case you want to use fixtures from a project that does not use entry points, you can
+define :globalvar:`pytest_plugins` in your top ``conftest.py`` file to register that module
+as a plugin.
+
+Suppose you have some fixtures in ``mylibrary.fixtures`` and you want to reuse them into your
+``app/tests`` directory.
+
+All you need to do is to define :globalvar:`pytest_plugins` in ``app/tests/conftest.py``
+pointing to that module.
+
+.. code-block:: python
+
+    pytest_plugins = "mylibrary.fixtures"
+
+This effectively registers ``mylibrary.fixtures`` as a plugin, making all its fixtures and
+hooks available to tests in ``app/tests``.
+
+.. note::
+
+    Sometimes users will *import* fixtures from other projects for use, however this is not
+    recommended: importing fixtures into a module will register them in pytest
+    as *defined* in that module.
+
+    This has minor consequences, such as appearing multiple times in ``pytest --help``,
+    but it is not **recommended** because this behavior might change/stop working
+    in future versions.

doc/en/funcarg_compare.rst

@@ -51,7 +51,7 @@ There are several limitations and difficulties with this approach:
    performs parametrization at the places where the resource
    is used.  Moreover, you need to modify the factory to use an
    ``extrakey`` parameter containing ``request.param`` to the
-   :py:func:`~python.Request.cached_setup` call.
+   ``Request.cached_setup`` call.
 
 3. Multiple parametrized session-scoped resources will be active
    at the same time, making it hard for them to affect global state
@@ -113,7 +113,7 @@ This new way of parametrizing funcarg factories should in many cases
 allow to re-use already written factories because effectively
 ``request.param`` was already used when test functions/classes were
 parametrized via
-:py:func:`~_pytest.python.Metafunc.parametrize(indirect=True)` calls.
+:py:func:`metafunc.parametrize(indirect=True) <_pytest.python.Metafunc.parametrize>` calls.
 
 Of course it's perfectly fine to combine parametrization and scoping:
 

doc/en/getting-started.rst

@@ -1,7 +1,7 @@
 Installation and Getting Started
 ===================================
 
-**Pythons**: Python 3.5, 3.6, 3.7, 3.8, 3.9, PyPy3
+**Pythons**: Python 3.6, 3.7, 3.8, 3.9, PyPy3
 
 **Platforms**: Linux and Windows
 
@@ -28,7 +28,7 @@ Install ``pytest``
 .. code-block:: bash
 
     $ pytest --version
-    pytest 6.0.0
+    pytest 6.2.0
 
 .. _`simpletest`:
 

doc/en/historical-notes.rst

@@ -112,7 +112,7 @@ More details can be found in the `original PR <https://github.com/pytest-dev/pyt
 .. note::
 
     in a future major release of pytest we will introduce class based markers,
-    at which point markers will no longer be limited to instances of :py:class:`Mark`.
+    at which point markers will no longer be limited to instances of :py:class:`~_pytest.mark.Mark`.
 
 
 cache plugin integrated into the core

doc/en/index.rst

@@ -1,5 +1,11 @@
 :orphan:
 
+.. sidebar:: Next Open Trainings
+
+   - `Professional testing with Python <https://www.python-academy.com/courses/specialtopics/python_course_testing.html>`_, via Python Academy, February 1-3 2021, Leipzig (Germany) and remote.
+
+   Also see `previous talks and blogposts <talks.html>`_.
+
 .. _features:
 
 pytest: helps you write better programs
@@ -55,17 +61,17 @@ See :ref:`Getting Started <getstarted>` for more examples.
 Features
 --------
 
-- Detailed info on failing :ref:`assert statements <assert>` (no need to remember ``self.assert*`` names);
+- Detailed info on failing :ref:`assert statements <assert>` (no need to remember ``self.assert*`` names)
 
-- :ref:`Auto-discovery <test discovery>` of test modules and functions;
+- :ref:`Auto-discovery <test discovery>` of test modules and functions
 
-- :ref:`Modular fixtures <fixture>` for managing small or parametrized long-lived test resources;
+- :ref:`Modular fixtures <fixture>` for managing small or parametrized long-lived test resources
 
-- Can run :ref:`unittest <unittest>` (including trial) and :ref:`nose <noseintegration>` test suites out of the box;
+- Can run :ref:`unittest <unittest>` (including trial) and :ref:`nose <noseintegration>` test suites out of the box
 
-- Python 3.5+ and PyPy 3;
+- Python 3.6+ and PyPy 3
 
-- Rich plugin architecture, with over 315+ `external plugins <http://plugincompat.herokuapp.com>`_ and thriving community;
+- Rich plugin architecture, with over 315+ `external plugins <http://plugincompat.herokuapp.com>`_ and thriving community
 
 
 Documentation

doc/en/mark.rst

@@ -43,7 +43,17 @@ You can register custom marks in your ``pytest.ini`` file like this:
         slow: marks tests as slow (deselect with '-m "not slow"')
         serial
 
-Note that everything after the ``:`` is an optional description.
+or in your ``pyproject.toml`` file like this:
+
+.. code-block:: toml
+
+    [tool.pytest.ini_options]
+    markers = [
+        "slow: marks tests as slow (deselect with '-m \"not slow\"')",
+        "serial",
+    ]
+
+Note that everything past the ``:`` after the mark name is an optional description.
 
 Alternatively, you can register new markers programmatically in a
 :ref:`pytest_configure <initialization-hooks>` hook:
@@ -66,7 +76,7 @@ Raising errors on unknown marks
 
 Unregistered marks applied with the ``@pytest.mark.name_of_the_mark`` decorator
 will always emit a warning in order to avoid silently doing something
-surprising due to mis-typed names. As described in the previous section, you can disable
+surprising due to mistyped names. As described in the previous section, you can disable
 the warning for custom marks by registering them in your ``pytest.ini`` file or
 using a custom ``pytest_configure`` hook.
 

doc/en/monkeypatch.rst

@@ -33,25 +33,25 @@ Consider the following scenarios:
 
 1. Modifying the behavior of a function or the property of a class for a test e.g.
 there is an API call or database connection you will not make for a test but you know
-what the expected output should be. Use :py:meth:`monkeypatch.setattr` to patch the
+what the expected output should be. Use :py:meth:`monkeypatch.setattr <MonkeyPatch.setattr>` to patch the
 function or property with your desired testing behavior. This can include your own functions.
-Use :py:meth:`monkeypatch.delattr` to remove the function or property for the test.
+Use :py:meth:`monkeypatch.delattr <MonkeyPatch.delattr>` to remove the function or property for the test.
 
 2. Modifying the values of dictionaries e.g. you have a global configuration that
-you want to modify for certain test cases. Use :py:meth:`monkeypatch.setitem` to patch the
-dictionary for the test. :py:meth:`monkeypatch.delitem` can be used to remove items.
+you want to modify for certain test cases. Use :py:meth:`monkeypatch.setitem <MonkeyPatch.setitem>` to patch the
+dictionary for the test. :py:meth:`monkeypatch.delitem <MonkeyPatch.delitem>` can be used to remove items.
 
 3. Modifying environment variables for a test e.g. to test program behavior if an
 environment variable is missing, or to set multiple values to a known variable.
-:py:meth:`monkeypatch.setenv` and :py:meth:`monkeypatch.delenv` can be used for
+:py:meth:`monkeypatch.setenv <MonkeyPatch.setenv>` and :py:meth:`monkeypatch.delenv <MonkeyPatch.delenv>` can be used for
 these patches.
 
 4. Use ``monkeypatch.setenv("PATH", value, prepend=os.pathsep)`` to modify ``$PATH``, and
-:py:meth:`monkeypatch.chdir` to change the context of the current working directory
+:py:meth:`monkeypatch.chdir <MonkeyPatch.chdir>` to change the context of the current working directory
 during a test.
 
-5. Use :py:meth:`monkeypatch.syspath_prepend` to modify ``sys.path`` which will also
-call :py:meth:`pkg_resources.fixup_namespace_packages` and :py:meth:`importlib.invalidate_caches`.
+5. Use :py:meth:`monkeypatch.syspath_prepend <MonkeyPatch.syspath_prepend>` to modify ``sys.path`` which will also
+call ``pkg_resources.fixup_namespace_packages`` and :py:func:`importlib.invalidate_caches`.
 
 See the `monkeypatch blog post`_ for some introduction material
 and a discussion of its motivation.
@@ -66,10 +66,10 @@ testing, you do not want your test to depend on the running user. ``monkeypatch`
 can be used to patch functions dependent on the user to always return a
 specific value.
 
-In this example, :py:meth:`monkeypatch.setattr` is used to patch ``Path.home``
+In this example, :py:meth:`monkeypatch.setattr <MonkeyPatch.setattr>` is used to patch ``Path.home``
 so that the known testing path ``Path("/abc")`` is always used when the test is run.
 This removes any dependency on the running user for testing purposes.
-:py:meth:`monkeypatch.setattr` must be called before the function which will use
+:py:meth:`monkeypatch.setattr <MonkeyPatch.setattr>` must be called before the function which will use
 the patched function is called.
 After the test function finishes the ``Path.home`` modification will be undone.
 
@@ -102,7 +102,7 @@ After the test function finishes the ``Path.home`` modification will be undone.
 Monkeypatching returned objects: building mock classes
 ------------------------------------------------------
 
-:py:meth:`monkeypatch.setattr` can be used in conjunction with classes to mock returned
+:py:meth:`monkeypatch.setattr <MonkeyPatch.setattr>` can be used in conjunction with classes to mock returned
 objects from functions instead of values.
 Imagine a simple function to take an API url and return the json response.
 
@@ -330,7 +330,7 @@ This behavior can be moved into ``fixture`` structures and shared across tests:
 Monkeypatching dictionaries
 ---------------------------
 
-:py:meth:`monkeypatch.setitem` can be used to safely set the values of dictionaries
+:py:meth:`monkeypatch.setitem <MonkeyPatch.setitem>` can be used to safely set the values of dictionaries
 to specific values during tests. Take this simplified connection string example:
 
 .. code-block:: python
@@ -367,7 +367,7 @@ For testing purposes we can patch the ``DEFAULT_CONFIG`` dictionary to specific
         result = app.create_connection_string()
         assert result == expected
 
-You can use the :py:meth:`monkeypatch.delitem` to remove values.
+You can use the :py:meth:`monkeypatch.delitem <MonkeyPatch.delitem>` to remove values.
 
 .. code-block:: python
 

doc/en/nose.rst

@@ -68,4 +68,13 @@ Unsupported idioms / known issues
   fundamentally incompatible with pytest because they don't support fixtures
   properly since collection and test execution are separated.
 
+Migrating from nose to pytest
+------------------------------
+
+`nose2pytest <https://github.com/pytest-dev/nose2pytest>`_ is a Python script
+and pytest plugin to help convert Nose-based tests into pytest-based tests.
+Specifically, the script transforms nose.tools.assert_* function calls into
+raw assert statements, while preserving format of original arguments
+as much as possible.
+
 .. _nose: https://nose.readthedocs.io/en/latest/

doc/en/reference.rst

@@ -182,14 +182,14 @@ Mark a test function as using the given fixture names.
 
 .. py:function:: pytest.mark.usefixtures(*names)
 
-    :param args: the names of the fixture to use, as strings
+    :param args: The names of the fixture to use, as strings.
 
 .. note::
 
     When using `usefixtures` in hooks, it can only load fixtures when applied to a test function before test setup
     (for example in the `pytest_collection_modifyitems` hook).
 
-    Also not that his mark has no effect when applied to **fixtures**.
+    Also note that this mark has no effect when applied to **fixtures**.
 
 
 
@@ -209,8 +209,10 @@ Marks a test function as *expected to fail*.
         Condition for marking the test function as xfail (``True/False`` or a
         :ref:`condition string <string conditions>`). If a bool, you also have
         to specify ``reason`` (see :ref:`condition string <string conditions>`).
-    :keyword str reason: Reason why the test function is marked as xfail.
-    :keyword Exception raises: Exception subclass expected to be raised by the test function; other exceptions will fail the test.
+    :keyword str reason:
+        Reason why the test function is marked as xfail.
+    :keyword Type[Exception] raises:
+        Exception subclass expected to be raised by the test function; other exceptions will fail the test.
     :keyword bool run:
         If the test function should actually be executed. If ``False``, the function will always xfail and will
         not be executed (useful if a function is segfaulting).
@@ -224,7 +226,7 @@ Marks a test function as *expected to fail*.
           a new release of a library fixes a known bug).
 
 
-custom marks
+Custom marks
 ~~~~~~~~~~~~
 
 Marks are created dynamically using the factory object ``pytest.mark`` and applied as a decorator.
@@ -238,7 +240,7 @@ For example:
         ...
 
 Will create and attach a :class:`Mark <_pytest.mark.structures.Mark>` object to the collected
-:class:`Item <_pytest.nodes.Item>`, which can then be accessed by fixtures or hooks with
+:class:`Item <pytest.Item>`, which can then be accessed by fixtures or hooks with
 :meth:`Node.iter_markers <_pytest.nodes.Node.iter_markers>`. The ``mark`` object will have the following attributes:
 
 .. code-block:: python
@@ -246,6 +248,16 @@ Will create and attach a :class:`Mark <_pytest.mark.structures.Mark>` object to
     mark.args == (10, "slow")
     mark.kwargs == {"method": "thread"}
 
+Example for using multiple custom markers:
+
+.. code-block:: python
+
+    @pytest.mark.timeout(10, "slow", method="thread")
+    @pytest.mark.slow
+    def test_function():
+        ...
+
+When :meth:`Node.iter_markers <_pytest.nodes.Node.iter_markers>` or :meth:`Node.iter_markers <_pytest.nodes.Node.iter_markers_with_node>` is used with multiple markers, the marker closest to the function will be iterated over first. The above example will result in ``@pytest.mark.slow`` followed by ``@pytest.mark.timeout(...)``.
 
 .. _`fixtures-api`:
 
@@ -302,11 +314,10 @@ request ``pytestconfig`` into your fixture and get it with ``pytestconfig.cache`
 Under the hood, the cache plugin uses the simple
 ``dumps``/``loads`` API of the :py:mod:`json` stdlib module.
 
-.. currentmodule:: _pytest.cacheprovider
+``config.cache`` is an instance of :class:`pytest.Cache`:
 
-.. automethod:: Cache.get
-.. automethod:: Cache.set
-.. automethod:: Cache.makedir
+.. autoclass:: pytest.Cache()
+   :members:
 
 
 .. fixture:: capsys
@@ -316,12 +327,10 @@ capsys
 
 **Tutorial**: :doc:`capture`.
 
-.. currentmodule:: _pytest.capture
-
-.. autofunction:: capsys()
+.. autofunction:: _pytest.capture.capsys()
     :no-auto-options:
 
-    Returns an instance of :py:class:`CaptureFixture`.
+    Returns an instance of :class:`CaptureFixture[str] <pytest.CaptureFixture>`.
 
     Example:
 
@@ -332,7 +341,7 @@ capsys
             captured = capsys.readouterr()
             assert captured.out == "hello\n"
 
-.. autoclass:: CaptureFixture()
+.. autoclass:: pytest.CaptureFixture()
     :members:
 
 
@@ -343,10 +352,10 @@ capsysbinary
 
 **Tutorial**: :doc:`capture`.
 
-.. autofunction:: capsysbinary()
+.. autofunction:: _pytest.capture.capsysbinary()
     :no-auto-options:
 
-    Returns an instance of :py:class:`CaptureFixture`.
+    Returns an instance of :class:`CaptureFixture[bytes] <pytest.CaptureFixture>`.
 
     Example:
 
@@ -365,10 +374,10 @@ capfd
 
 **Tutorial**: :doc:`capture`.
 
-.. autofunction:: capfd()
+.. autofunction:: _pytest.capture.capfd()
     :no-auto-options:
 
-    Returns an instance of :py:class:`CaptureFixture`.
+    Returns an instance of :class:`CaptureFixture[str] <pytest.CaptureFixture>`.
 
     Example:
 
@@ -387,10 +396,10 @@ capfdbinary
 
 **Tutorial**: :doc:`capture`.
 
-.. autofunction:: capfdbinary()
+.. autofunction:: _pytest.capture.capfdbinary()
     :no-auto-options:
 
-    Returns an instance of :py:class:`CaptureFixture`.
+    Returns an instance of :class:`CaptureFixture[bytes] <pytest.CaptureFixture>`.
 
     Example:
 
@@ -431,7 +440,7 @@ request
 
 The ``request`` fixture is a special fixture providing information of the requesting test function.
 
-.. autoclass:: _pytest.fixtures.FixtureRequest()
+.. autoclass:: pytest.FixtureRequest()
     :members:
 
 
@@ -473,9 +482,9 @@ caplog
 .. autofunction:: _pytest.logging.caplog()
     :no-auto-options:
 
-    This returns a :class:`_pytest.logging.LogCaptureFixture` instance.
+    Returns a :class:`pytest.LogCaptureFixture` instance.
 
-.. autoclass:: _pytest.logging.LogCaptureFixture
+.. autoclass:: pytest.LogCaptureFixture()
     :members:
 
 
@@ -484,30 +493,30 @@ caplog
 monkeypatch
 ~~~~~~~~~~~
 
-.. currentmodule:: _pytest.monkeypatch
-
 **Tutorial**: :doc:`monkeypatch`.
 
 .. autofunction:: _pytest.monkeypatch.monkeypatch()
     :no-auto-options:
 
-    This returns a :class:`MonkeyPatch` instance.
+    Returns a :class:`~pytest.MonkeyPatch` instance.
 
-.. autoclass:: _pytest.monkeypatch.MonkeyPatch
+.. autoclass:: pytest.MonkeyPatch
     :members:
 
 
-.. fixture:: testdir
+.. fixture:: pytester
 
-testdir
-~~~~~~~
+pytester
+~~~~~~~~
 
-.. currentmodule:: _pytest.pytester
+.. versionadded:: 6.2
 
-This fixture provides a :class:`Testdir` instance useful for black-box testing of test files, making it ideal to
-test plugins.
+Provides a :class:`~pytest.Pytester` instance that can be used to run and test pytest itself.
 
-To use it, include in your top-most ``conftest.py`` file:
+It provides an empty directory where pytest can be executed in isolation, and contains facilities
+to write tests, configuration files, and match against expected output.
+
+To use it, include in your topmost ``conftest.py`` file:
 
 .. code-block:: python
 
@@ -515,13 +524,30 @@ To use it, include in your top-most ``conftest.py`` file:
 
 
 
-.. autoclass:: Testdir()
+.. autoclass:: pytest.Pytester()
     :members:
 
-.. autoclass:: RunResult()
+.. autoclass:: _pytest.pytester.RunResult()
     :members:
 
-.. autoclass:: LineMatcher()
+.. autoclass:: _pytest.pytester.LineMatcher()
+    :members:
+    :special-members: __str__
+
+.. autoclass:: _pytest.pytester.HookRecorder()
+    :members:
+
+.. fixture:: testdir
+
+testdir
+~~~~~~~
+
+Identical to :fixture:`pytester`, but provides an instance whose methods return
+legacy ``py.path.local`` objects instead when applicable.
+
+New code should avoid using :fixture:`testdir` in favor of :fixture:`pytester`.
+
+.. autoclass:: pytest.Testdir()
     :members:
 
 
@@ -532,19 +558,14 @@ recwarn
 
 **Tutorial**: :ref:`assertwarnings`
 
-.. currentmodule:: _pytest.recwarn
-
-.. autofunction:: recwarn()
+.. autofunction:: _pytest.recwarn.recwarn()
     :no-auto-options:
 
-.. autoclass:: _pytest.recwarn.WarningsRecorder()
+.. autoclass:: pytest.WarningsRecorder()
     :members:
 
 Each recorded warning is an instance of :class:`warnings.WarningMessage`.
 
-.. note::
-    :class:`RecordedWarning` was changed from a plain class to a namedtuple in pytest 3.1
-
 .. note::
     ``DeprecationWarning`` and ``PendingDeprecationWarning`` are treated
     differently; see :ref:`ensuring_function_triggers`.
@@ -557,13 +578,11 @@ tmp_path
 
 **Tutorial**: :doc:`tmpdir`
 
-.. currentmodule:: _pytest.tmpdir
-
-.. autofunction:: tmp_path()
+.. autofunction:: _pytest.tmpdir.tmp_path()
     :no-auto-options:
 
 
-.. fixture:: tmp_path_factory
+.. fixture:: _pytest.tmpdir.tmp_path_factory
 
 tmp_path_factory
 ~~~~~~~~~~~~~~~~
@@ -572,12 +591,9 @@ tmp_path_factory
 
 .. _`tmp_path_factory factory api`:
 
-``tmp_path_factory`` instances have the following methods:
+``tmp_path_factory`` is an instance of :class:`~pytest.TempPathFactory`:
 
-.. currentmodule:: _pytest.tmpdir
-
-.. automethod:: TempPathFactory.mktemp
-.. automethod:: TempPathFactory.getbasetemp
+.. autoclass:: pytest.TempPathFactory()
 
 
 .. fixture:: tmpdir
@@ -587,9 +603,7 @@ tmpdir
 
 **Tutorial**: :doc:`tmpdir`
 
-.. currentmodule:: _pytest.tmpdir
-
-.. autofunction:: tmpdir()
+.. autofunction:: _pytest.tmpdir.tmpdir()
     :no-auto-options:
 
 
@@ -602,12 +616,9 @@ tmpdir_factory
 
 .. _`tmpdir factory api`:
 
-``tmpdir_factory`` instances have the following methods:
+``tmp_path_factory`` is an instance of :class:`~pytest.TempdirFactory`:
 
-.. currentmodule:: _pytest.tmpdir
-
-.. automethod:: TempdirFactory.mktemp
-.. automethod:: TempdirFactory.getbasetemp
+.. autoclass:: pytest.TempdirFactory()
 
 
 .. _`hook-reference`:
@@ -654,7 +665,6 @@ Collection hooks
 
 .. autofunction:: pytest_collection
 .. autofunction:: pytest_ignore_collect
-.. autofunction:: pytest_collect_directory
 .. autofunction:: pytest_collect_file
 .. autofunction:: pytest_pycollect_makemodule
 
@@ -670,12 +680,16 @@ items, delete or otherwise amend the test items:
 
 .. autofunction:: pytest_collection_modifyitems
 
+.. note::
+    If this hook is implemented in ``conftest.py`` files, it always receives all collected items, not only those
+    under the ``conftest.py`` where it is implemented.
+
 .. autofunction:: pytest_collection_finish
 
 Test running (runtest) hooks
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-All runtest related hooks receive a :py:class:`pytest.Item <_pytest.main.Item>` object.
+All runtest related hooks receive a :py:class:`pytest.Item <pytest.Item>` object.
 
 .. autofunction:: pytest_runtestloop
 .. autofunction:: pytest_runtest_protocol
@@ -687,8 +701,8 @@ All runtest related hooks receive a :py:class:`pytest.Item <_pytest.main.Item>`
 .. autofunction:: pytest_runtest_makereport
 
 For deeper understanding you may look at the default implementation of
-these hooks in :py:mod:`_pytest.runner` and maybe also
-in :py:mod:`_pytest.pdb` which interacts with :py:mod:`_pytest.capture`
+these hooks in ``_pytest.runner`` and maybe also
+in ``_pytest.pdb`` which interacts with ``_pytest.capture``
 and its input/output capturing in order to immediately drop
 into interactive debugging when a test failure occurs.
 
@@ -751,14 +765,14 @@ CallInfo
 Class
 ~~~~~
 
-.. autoclass:: _pytest.python.Class()
+.. autoclass:: pytest.Class()
     :members:
     :show-inheritance:
 
 Collector
 ~~~~~~~~~
 
-.. autoclass:: _pytest.nodes.Collector()
+.. autoclass:: pytest.Collector()
     :members:
     :show-inheritance:
 
@@ -783,12 +797,19 @@ ExceptionInfo
     :members:
 
 
-pytest.ExitCode
-~~~~~~~~~~~~~~~
+ExitCode
+~~~~~~~~
 
-.. autoclass:: _pytest.config.ExitCode
+.. autoclass:: pytest.ExitCode
     :members:
 
+File
+~~~~
+
+.. autoclass:: pytest.File()
+    :members:
+    :show-inheritance:
+
 
 FixtureDef
 ~~~~~~~~~~
@@ -807,14 +828,21 @@ FSCollector
 Function
 ~~~~~~~~
 
-.. autoclass:: _pytest.python.Function()
+.. autoclass:: pytest.Function()
+    :members:
+    :show-inheritance:
+
+FunctionDefinition
+~~~~~~~~~~~~~~~~~~
+
+.. autoclass:: _pytest.python.FunctionDefinition()
     :members:
     :show-inheritance:
 
 Item
 ~~~~
 
-.. autoclass:: _pytest.nodes.Item()
+.. autoclass:: pytest.Item()
     :members:
     :show-inheritance:
 
@@ -848,7 +876,7 @@ Metafunc
 Module
 ~~~~~~
 
-.. autoclass:: _pytest.python.Module()
+.. autoclass:: pytest.Module()
     :members:
     :show-inheritance:
 
@@ -864,12 +892,6 @@ Parser
 .. autoclass:: _pytest.config.argparsing.Parser()
     :members:
 
-PluginManager
-~~~~~~~~~~~~~
-
-.. autoclass:: pluggy.PluginManager()
-    :members:
-
 
 PytestPluginManager
 ~~~~~~~~~~~~~~~~~~~
@@ -877,12 +899,13 @@ PytestPluginManager
 .. autoclass:: _pytest.config.PytestPluginManager()
     :members:
     :undoc-members:
+    :inherited-members:
     :show-inheritance:
 
 Session
 ~~~~~~~
 
-.. autoclass:: _pytest.main.Session()
+.. autoclass:: pytest.Session()
     :members:
     :show-inheritance:
 
@@ -1024,7 +1047,7 @@ When set (regardless of value), pytest will use color in terminal output.
 Exceptions
 ----------
 
-.. autoclass:: _pytest.config.UsageError()
+.. autoclass:: pytest.UsageError()
     :show-inheritance:
 
 .. _`warnings ref`:
@@ -1061,6 +1084,12 @@ Custom warnings generated in some situations such as improper usage or deprecate
 .. autoclass:: pytest.PytestUnknownMarkWarning
    :show-inheritance:
 
+.. autoclass:: pytest.PytestUnraisableExceptionWarning
+   :show-inheritance:
+
+.. autoclass:: pytest.PytestUnhandledThreadExceptionWarning
+   :show-inheritance:
+
 
 Consult the :ref:`internal-warnings` section in the documentation for more information.
 
@@ -1236,12 +1265,13 @@ passed multiple times. The expected format is ``name=value``. For example::
 .. confval:: junit_family
 
     .. versionadded:: 4.2
+    .. versionchanged:: 6.1
+        Default changed to ``xunit2``.
 
     Configures the format of the generated JUnit XML file. The possible options are:
 
-    * ``xunit1`` (or ``legacy``): produces old style output, compatible with the xunit 1.0 format. **This is the default**.
-    * ``xunit2``: produces `xunit 2.0 style output <https://github.com/jenkinsci/xunit-plugin/blob/xunit-2.3.2/src/main/resources/org/jenkinsci/plugins/xunit/types/model/xsd/junit-10.xsd>`__,
-        which should be more compatible with latest Jenkins versions.
+    * ``xunit1`` (or ``legacy``): produces old style output, compatible with the xunit 1.0 format.
+    * ``xunit2``: produces `xunit 2.0 style output <https://github.com/jenkinsci/xunit-plugin/blob/xunit-2.3.2/src/main/resources/org/jenkinsci/plugins/xunit/types/model/xsd/junit-10.xsd>`__, which should be more compatible with latest Jenkins versions.  **This is the default**.
 
     .. code-block:: ini
 
@@ -1466,20 +1496,6 @@ passed multiple times. The expected format is ``name=value``. For example::
     For more information, see :ref:`logging`.
 
 
-.. confval:: log_print
-
-
-
-    If set to ``False``, will disable displaying captured logging messages for failed tests.
-
-    .. code-block:: ini
-
-        [pytest]
-        log_print = False
-
-    For more information, see :ref:`logging`.
-
-
 .. confval:: markers
 
     When the ``--strict-markers`` or ``--strict`` command-line arguments are used,
@@ -1525,7 +1541,8 @@ passed multiple times. The expected format is ``name=value``. For example::
         [seq]   matches any character in seq
         [!seq]  matches any char not in seq
 
-   Default patterns are ``'.*', 'build', 'dist', 'CVS', '_darcs', '{arch}', '*.egg', 'venv'``.
+   Default patterns are ``'*.egg'``, ``'.*'``, ``'_darcs'``, ``'build'``,
+   ``'CVS'``, ``'dist'``, ``'node_modules'``, ``'venv'``, ``'{arch}'``.
    Setting a ``norecursedirs`` replaces the default.  Here is an example of
    how to avoid certain directories:
 
@@ -1666,3 +1683,297 @@ passed multiple times. The expected format is ``name=value``. For example::
 
         [pytest]
         xfail_strict = True
+
+
+.. _`command-line-flags`:
+
+Command-line Flags
+------------------
+
+All the command-line flags can be obtained by running ``pytest --help``::
+
+    $ pytest --help
+    usage: pytest [options] [file_or_dir] [file_or_dir] [...]
+
+    positional arguments:
+      file_or_dir
+
+    general:
+      -k EXPRESSION         only run tests which match the given substring
+                            expression. An expression is a python evaluatable
+                            expression where all names are substring-matched
+                            against test names and their parent classes.
+                            Example: -k 'test_method or test_other' matches all
+                            test functions and classes whose name contains
+                            'test_method' or 'test_other', while -k 'not
+                            test_method' matches those that don't contain
+                            'test_method' in their names. -k 'not test_method
+                            and not test_other' will eliminate the matches.
+                            Additionally keywords are matched to classes and
+                            functions containing extra names in their
+                            'extra_keyword_matches' set, as well as functions
+                            which have names assigned directly to them. The
+                            matching is case-insensitive.
+      -m MARKEXPR           only run tests matching given mark expression.
+                            For example: -m 'mark1 and not mark2'.
+      --markers             show markers (builtin, plugin and per-project ones).
+      -x, --exitfirst       exit instantly on first error or failed test.
+      --fixtures, --funcargs
+                            show available fixtures, sorted by plugin appearance
+                            (fixtures with leading '_' are only shown with '-v')
+      --fixtures-per-test   show fixtures per test
+      --pdb                 start the interactive Python debugger on errors or
+                            KeyboardInterrupt.
+      --pdbcls=modulename:classname
+                            start a custom interactive Python debugger on
+                            errors. For example:
+                            --pdbcls=IPython.terminal.debugger:TerminalPdb
+      --trace               Immediately break when running each test.
+      --capture=method      per-test capturing method: one of fd|sys|no|tee-sys.
+      -s                    shortcut for --capture=no.
+      --runxfail            report the results of xfail tests as if they were
+                            not marked
+      --lf, --last-failed   rerun only the tests that failed at the last run (or
+                            all if none failed)
+      --ff, --failed-first  run all tests, but run the last failures first.
+                            This may re-order tests and thus lead to repeated
+                            fixture setup/teardown.
+      --nf, --new-first     run tests from new files first, then the rest of the
+                            tests sorted by file mtime
+      --cache-show=[CACHESHOW]
+                            show cache contents, don't perform collection or
+                            tests. Optional argument: glob (default: '*').
+      --cache-clear         remove all cache contents at start of test run.
+      --lfnf={all,none}, --last-failed-no-failures={all,none}
+                            which tests to run with no previously (known)
+                            failures.
+      --sw, --stepwise      exit on test failure and continue from last failing
+                            test next time
+      --sw-skip, --stepwise-skip
+                            ignore the first failing test but stop on the next
+                            failing test
+
+    reporting:
+      --durations=N         show N slowest setup/test durations (N=0 for all).
+      --durations-min=N     Minimal duration in seconds for inclusion in slowest
+                            list. Default 0.005
+      -v, --verbose         increase verbosity.
+      --no-header           disable header
+      --no-summary          disable summary
+      -q, --quiet           decrease verbosity.
+      --verbosity=VERBOSE   set verbosity. Default is 0.
+      -r chars              show extra test summary info as specified by chars:
+                            (f)ailed, (E)rror, (s)kipped, (x)failed, (X)passed,
+                            (p)assed, (P)assed with output, (a)ll except passed
+                            (p/P), or (A)ll. (w)arnings are enabled by default
+                            (see --disable-warnings), 'N' can be used to reset
+                            the list. (default: 'fE').
+      --disable-warnings, --disable-pytest-warnings
+                            disable warnings summary
+      -l, --showlocals      show locals in tracebacks (disabled by default).
+      --tb=style            traceback print mode
+                            (auto/long/short/line/native/no).
+      --show-capture={no,stdout,stderr,log,all}
+                            Controls how captured stdout/stderr/log is shown on
+                            failed tests. Default is 'all'.
+      --full-trace          don't cut any tracebacks (default is to cut).
+      --color=color         color terminal output (yes/no/auto).
+      --code-highlight={yes,no}
+                            Whether code should be highlighted (only if --color
+                            is also enabled)
+      --pastebin=mode       send failed|all info to bpaste.net pastebin service.
+      --junit-xml=path      create junit-xml style report file at given path.
+      --junit-prefix=str    prepend prefix to classnames in junit-xml output
+
+    pytest-warnings:
+      -W PYTHONWARNINGS, --pythonwarnings=PYTHONWARNINGS
+                            set which warnings to report, see -W option of
+                            python itself.
+      --maxfail=num         exit after first num failures or errors.
+      --strict-config       any warnings encountered while parsing the `pytest`
+                            section of the configuration file raise errors.
+      --strict-markers      markers not registered in the `markers` section of
+                            the configuration file raise errors.
+      --strict              (deprecated) alias to --strict-markers.
+      -c file               load configuration from `file` instead of trying to
+                            locate one of the implicit configuration files.
+      --continue-on-collection-errors
+                            Force test execution even if collection errors
+                            occur.
+      --rootdir=ROOTDIR     Define root directory for tests. Can be relative
+                            path: 'root_dir', './root_dir',
+                            'root_dir/another_dir/'; absolute path:
+                            '/home/user/root_dir'; path with variables:
+                            '$HOME/root_dir'.
+
+    collection:
+      --collect-only, --co  only collect tests, don't execute them.
+      --pyargs              try to interpret all arguments as python packages.
+      --ignore=path         ignore path during collection (multi-allowed).
+      --ignore-glob=path    ignore path pattern during collection (multi-
+                            allowed).
+      --deselect=nodeid_prefix
+                            deselect item (via node id prefix) during collection
+                            (multi-allowed).
+      --confcutdir=dir      only load conftest.py's relative to specified dir.
+      --noconftest          Don't load any conftest.py files.
+      --keep-duplicates     Keep duplicate tests.
+      --collect-in-virtualenv
+                            Don't ignore tests in a local virtualenv directory
+      --import-mode={prepend,append,importlib}
+                            prepend/append to sys.path when importing test
+                            modules and conftest files, default is to prepend.
+      --doctest-modules     run doctests in all .py modules
+      --doctest-report={none,cdiff,ndiff,udiff,only_first_failure}
+                            choose another output format for diffs on doctest
+                            failure
+      --doctest-glob=pat    doctests file matching pattern, default: test*.txt
+      --doctest-ignore-import-errors
+                            ignore doctest ImportErrors
+      --doctest-continue-on-failure
+                            for a given doctest, continue to run after the first
+                            failure
+
+    test session debugging and configuration:
+      --basetemp=dir        base temporary directory for this test run.(warning:
+                            this directory is removed if it exists)
+      -V, --version         display pytest version and information about
+                            plugins.When given twice, also display information
+                            about plugins.
+      -h, --help            show help message and configuration info
+      -p name               early-load given plugin module name or entry point
+                            (multi-allowed).
+                            To avoid loading of plugins, use the `no:` prefix,
+                            e.g. `no:doctest`.
+      --trace-config        trace considerations of conftest.py files.
+      --debug               store internal tracing debug information in
+                            'pytestdebug.log'.
+      -o OVERRIDE_INI, --override-ini=OVERRIDE_INI
+                            override ini option with "option=value" style, e.g.
+                            `-o xfail_strict=True -o cache_dir=cache`.
+      --assert=MODE         Control assertion debugging tools.
+                            'plain' performs no assertion debugging.
+                            'rewrite' (the default) rewrites assert statements
+                            in test modules on import to provide assert
+                            expression information.
+      --setup-only          only setup fixtures, do not execute tests.
+      --setup-show          show setup of fixtures while executing tests.
+      --setup-plan          show what fixtures and tests would be executed but
+                            don't execute anything.
+
+    logging:
+      --log-level=LEVEL     level of messages to catch/display.
+                            Not set by default, so it depends on the root/parent
+                            log handler's effective level, where it is "WARNING"
+                            by default.
+      --log-format=LOG_FORMAT
+                            log format as used by the logging module.
+      --log-date-format=LOG_DATE_FORMAT
+                            log date format as used by the logging module.
+      --log-cli-level=LOG_CLI_LEVEL
+                            cli logging level.
+      --log-cli-format=LOG_CLI_FORMAT
+                            log format as used by the logging module.
+      --log-cli-date-format=LOG_CLI_DATE_FORMAT
+                            log date format as used by the logging module.
+      --log-file=LOG_FILE   path to a file when logging will be written to.
+      --log-file-level=LOG_FILE_LEVEL
+                            log file logging level.
+      --log-file-format=LOG_FILE_FORMAT
+                            log format as used by the logging module.
+      --log-file-date-format=LOG_FILE_DATE_FORMAT
+                            log date format as used by the logging module.
+      --log-auto-indent=LOG_AUTO_INDENT
+                            Auto-indent multiline messages passed to the logging
+                            module. Accepts true|on, false|off or an integer.
+
+    [pytest] ini-options in the first pytest.ini|tox.ini|setup.cfg file found:
+
+      markers (linelist):   markers for test functions
+      empty_parameter_set_mark (string):
+                            default marker for empty parametersets
+      norecursedirs (args): directory patterns to avoid for recursion
+      testpaths (args):     directories to search for tests when no files or
+                            directories are given in the command line.
+      filterwarnings (linelist):
+                            Each line specifies a pattern for
+                            warnings.filterwarnings. Processed after
+                            -W/--pythonwarnings.
+      usefixtures (args):   list of default fixtures to be used with this
+                            project
+      python_files (args):  glob-style file patterns for Python test module
+                            discovery
+      python_classes (args):
+                            prefixes or glob names for Python test class
+                            discovery
+      python_functions (args):
+                            prefixes or glob names for Python test function and
+                            method discovery
+      disable_test_id_escaping_and_forfeit_all_rights_to_community_support (bool):
+                            disable string escape non-ascii characters, might
+                            cause unwanted side effects(use at your own risk)
+      console_output_style (string):
+                            console output: "classic", or with additional
+                            progress information ("progress" (percentage) |
+                            "count").
+      xfail_strict (bool):  default for the strict parameter of xfail markers
+                            when not given explicitly (default: False)
+      enable_assertion_pass_hook (bool):
+                            Enables the pytest_assertion_pass hook.Make sure to
+                            delete any previously generated pyc cache files.
+      junit_suite_name (string):
+                            Test suite name for JUnit report
+      junit_logging (string):
+                            Write captured log messages to JUnit report: one of
+                            no|log|system-out|system-err|out-err|all
+      junit_log_passing_tests (bool):
+                            Capture log information for passing tests to JUnit
+                            report:
+      junit_duration_report (string):
+                            Duration time to report: one of total|call
+      junit_family (string):
+                            Emit XML for schema: one of legacy|xunit1|xunit2
+      doctest_optionflags (args):
+                            option flags for doctests
+      doctest_encoding (string):
+                            encoding used for doctest files
+      cache_dir (string):   cache directory path.
+      log_level (string):   default value for --log-level
+      log_format (string):  default value for --log-format
+      log_date_format (string):
+                            default value for --log-date-format
+      log_cli (bool):       enable log display during test run (also known as
+                            "live logging").
+      log_cli_level (string):
+                            default value for --log-cli-level
+      log_cli_format (string):
+                            default value for --log-cli-format
+      log_cli_date_format (string):
+                            default value for --log-cli-date-format
+      log_file (string):    default value for --log-file
+      log_file_level (string):
+                            default value for --log-file-level
+      log_file_format (string):
+                            default value for --log-file-format
+      log_file_date_format (string):
+                            default value for --log-file-date-format
+      log_auto_indent (string):
+                            default value for --log-auto-indent
+      faulthandler_timeout (string):
+                            Dump the traceback of all threads if a test takes
+                            more than TIMEOUT seconds to finish.
+      addopts (args):       extra command line options
+      minversion (string):  minimally required pytest version
+      required_plugins (args):
+                            plugins that must be present for pytest to run
+
+    environment variables:
+      PYTEST_ADDOPTS           extra command line options
+      PYTEST_PLUGINS           comma-separated plugins to load during startup
+      PYTEST_DISABLE_PLUGIN_AUTOLOAD set to disable plugin auto-loading
+      PYTEST_DEBUG             set to enable debug tracing of pytest's internals
+
+
+    to see available markers type: pytest --markers
+    to see available fixtures type: pytest --fixtures
+    (shown according to specified file_or_dir or current dir if not specified; fixtures with leading '_' are only shown with the '-v' option

doc/en/skipping.rst

@@ -91,7 +91,7 @@ when run on an interpreter earlier than Python3.6:
     import sys
 
 
-    @pytest.mark.skipif(sys.version_info < (3, 6), reason="requires python3.6 or higher")
+    @pytest.mark.skipif(sys.version_info < (3, 7), reason="requires python3.7 or higher")
     def test_function():
         ...
 
@@ -259,7 +259,7 @@ These two examples illustrate situations where you don't want to check for a con
 at the module level, which is when a condition would otherwise be evaluated for marks.
 
 This will make ``test_function`` ``XFAIL``. Note that no other code is executed after
-the ``pytest.xfail`` call, differently from the marker. That's because it is implemented
+the :func:`pytest.xfail` call, differently from the marker. That's because it is implemented
 internally by raising a known exception.
 
 **Reference**: :ref:`pytest.mark.xfail ref`
@@ -358,7 +358,7 @@ By specifying on the commandline:
     pytest --runxfail
 
 you can force the running and reporting of an ``xfail`` marked test
-as if it weren't marked at all. This also causes ``pytest.xfail`` to produce no effect.
+as if it weren't marked at all. This also causes :func:`pytest.xfail` to produce no effect.
 
 Examples
 ~~~~~~~~

doc/en/talks.rst

@@ -2,13 +2,6 @@
 Talks and Tutorials
 ==========================
 
-.. sidebar:: Next Open Trainings
-
-   - `Free 1h webinar: "pytest: Test Driven Development für Python" <https://mylearning.ch/kurse/online-kurse/tech-webinar/>`_ (German), online, August 18 2020.
-   - `"pytest: Test Driven Development (nicht nur) für Python" <https://workshoptage.ch/workshops/2020/pytest-test-driven-development-nicht-nur-fuer-python/>`_ (German) at the `CH Open Workshoptage <https://workshoptage.ch/>`_, September 8 2020, HSLU Campus Rotkreuz (ZG), Switzerland.
-
-.. _`funcargs`: funcargs.html
-
 Books
 ---------------------------------------------
 
@@ -21,6 +14,16 @@ Books
 Talks and blog postings
 ---------------------------------------------
 
+- Webinar: `pytest: Test Driven Development für Python (German) <https://bruhin.software/ins-pytest/>`_, Florian Bruhin, via mylearning.ch, 2020
+
+- Webinar: `Simplify Your Tests with Fixtures <https://blog.jetbrains.com/pycharm/2020/08/webinar-recording-simplify-your-tests-with-fixtures-with-oliver-bestwalter/>`_, Oliver Bestwalter, via JetBrains, 2020
+
+- Training: `Introduction to pytest - simple, rapid and fun testing with Python <https://www.youtube.com/watch?v=CMuSn9cofbI>`_, Florian Bruhin, PyConDE 2019
+
+- Abridged metaprogramming classics - this episode: pytest, Oliver Bestwalter, PyConDE 2019 (`repository <https://github.com/obestwalter/abridged-meta-programming-classics>`__, `recording <https://www.youtube.com/watch?v=zHpeMTJsBRk&feature=youtu.be>`__)
+
+- Testing PySide/PyQt code easily using the pytest framework, Florian Bruhin, Qt World Summit 2019 (`slides <https://bruhin.software/talks/qtws19.pdf>`__, `recording <https://www.youtube.com/watch?v=zdsBS5BXGqQ>`__)
+
 - `pytest: recommendations, basic packages for testing in Python and Django, Andreu Vallbona, PyBCN June 2019 <https://www.slideshare.net/AndreuVallbonaPlazas/pybcn-pytest-recomendaciones-paquetes-bsicos-para-testing-en-python-y-django>`_.
 
 - pytest: recommendations, basic packages for testing in Python and Django, Andreu Vallbona, PyconES 2017 (`slides in english <http://talks.apsl.io/testing-pycones-2017/>`_, `video in spanish <https://www.youtube.com/watch?v=K20GeR-lXDk>`_)
@@ -52,8 +55,6 @@ Talks and blog postings
 - `pytest: helps you write better Django apps, Andreas Pelme, DjangoCon
   Europe 2014 <https://www.youtube.com/watch?v=aaArYVh6XSM>`_.
 
-- :ref:`fixtures`
-
 - `Testing Django Applications with pytest, Andreas Pelme, EuroPython
   2013 <https://www.youtube.com/watch?v=aUf8Fkb7TaY>`_.
 

doc/en/tmpdir.rst

@@ -15,13 +15,11 @@ You can use the ``tmp_path`` fixture which will
 provide a temporary directory unique to the test invocation,
 created in the `base temporary directory`_.
 
-``tmp_path`` is a ``pathlib/pathlib2.Path`` object. Here is an example test usage:
+``tmp_path`` is a ``pathlib.Path`` object. Here is an example test usage:
 
 .. code-block:: python
 
     # content of test_tmp_path.py
-    import os
-
     CONTENT = "content"
 
 
@@ -63,7 +61,7 @@ Running this would result in a passed test except for the last
     >       assert 0
     E       assert 0
 
-    test_tmp_path.py:13: AssertionError
+    test_tmp_path.py:11: AssertionError
     ========================= short test summary info ==========================
     FAILED test_tmp_path.py::test_create_file - assert 0
     ============================ 1 failed in 0.12s =============================
@@ -97,9 +95,6 @@ and more.  Here is an example test usage:
 .. code-block:: python
 
     # content of test_tmpdir.py
-    import os
-
-
     def test_create_file(tmpdir):
         p = tmpdir.mkdir("sub").join("hello.txt")
         p.write("content")
@@ -134,7 +129,7 @@ Running this would result in a passed test except for the last
     >       assert 0
     E       assert 0
 
-    test_tmpdir.py:9: AssertionError
+    test_tmpdir.py:6: AssertionError
     ========================= short test summary info ==========================
     FAILED test_tmpdir.py::test_create_file - assert 0
     ============================ 1 failed in 0.12s =============================
@@ -192,8 +187,13 @@ You can override the default temporary directory setting like this:
 
     pytest --basetemp=mydir
 
-When distributing tests on the local machine, ``pytest`` takes care to
-configure a basetemp directory for the sub processes such that all temporary
+.. warning::
+
+    The contents of ``mydir`` will be completely removed, so make sure to use a directory
+    for that purpose only.
+
+When distributing tests on the local machine using ``pytest-xdist``, care is taken to
+automatically configure a basetemp directory for the sub processes such that all temporary
 data lands below a single per-test run basetemp directory.
 
 .. _`py.path.local`: https://py.readthedocs.io/en/latest/path.html

doc/en/usage.rst

@@ -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.config.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.ExitCode` enum. The exit codes being a part of the public API can be imported and accessed directly using:
 
 .. code-block:: python
 
@@ -57,6 +57,8 @@ Getting help on version, option names, environment variables
     pytest -h | --help # show help on command line and config file options
 
 
+The full command-line flags can be found in the :ref:`reference <command-line-flags>`.
+
 .. _maxfail:
 
 Stopping after the first (or N) failures
@@ -426,14 +428,15 @@ Pytest supports the use of ``breakpoint()`` with the following behaviours:
 Profiling test execution duration
 -------------------------------------
 
+.. versionchanged:: 6.0
 
-To get a list of the slowest 10 test durations:
+To get a list of the slowest 10 test durations over 1.0s long:
 
 .. code-block:: bash
 
-    pytest --durations=10
+    pytest --durations=10 --durations-min=1.0
 
-By default, pytest will not show test durations that are too small (<0.01s) unless ``-vv`` is passed on the command-line.
+By default, pytest will not show test durations that are too small (<0.005s) unless ``-vv`` is passed on the command-line.
 
 
 .. _faulthandler:
@@ -467,6 +470,38 @@ seconds to finish (not available on Windows).
       the command-line using ``-o faulthandler_timeout=X``.
 
 
+.. _unraisable:
+
+Warning about unraisable exceptions and unhandled thread exceptions
+-------------------------------------------------------------------
+
+.. versionadded:: 6.2
+
+.. note::
+
+    These features only work on Python>=3.8.
+
+Unhandled exceptions are exceptions that are raised in a situation in which
+they cannot propagate to a caller. The most common case is an exception raised
+in a :meth:`__del__ <object.__del__>` implementation.
+
+Unhandled thread exceptions are exceptions raised in a :class:`~threading.Thread`
+but not handled, causing the thread to terminate uncleanly.
+
+Both types of exceptions are normally considered bugs, but may go unnoticed
+because they don't cause the program itself to crash. Pytest detects these
+conditions and issues a warning that is visible in the test run summary.
+
+The plugins are automatically enabled for pytest runs, unless the
+``-p no:unraisableexception`` (for unraisable exceptions) and
+``-p no:threadexception`` (for thread exceptions) options are given on the
+command-line.
+
+The warnings may be silenced selectivly using the :ref:`pytest.mark.filterwarnings ref`
+mark. The warning categories are :class:`pytest.PytestUnraisableExceptionWarning` and
+:class:`pytest.PytestUnhandledThreadExceptionWarning`.
+
+
 Creating JUnitXML format files
 ----------------------------------------------------