test_ok2

History

Ran Benita 9cd14b4ffb doctest: fix autouse fixtures possibly not getting picked up Fix #11929. Figured out what's going on. We have the following collection tree: ``` <Dir pyspacewar> <Dir src> <Package pyspacewar> <Package tests> <DoctestModule test_main.py> <DoctestItem pyspacewar.tests.test_main.doctest_main> ``` And the `test_main.py` contains an autouse fixture (`fake_game_ui`) that `doctest_main` needs in order to run properly. The fixture doesn't run! It doesn't run because nothing collects the fixtures from (calls `parsefactories()` on) the `test_main.py` `DoctestModule`. How come it only started happening with commit ab63ebb3dc07b89670b96ae97044f48406c44fa0? Turns out it mostly only worked accidentally. Each `DoctestModule` is also collected as a normal `Module`, with the `Module` collected after the `DoctestModule`. For example, if we add a non-doctest test to `test_main.py`, the collection tree looks like this: ``` <Dir pyspacewar> <Dir src> <Package pyspacewar> <Package tests> <DoctestModule test_main.py> <DoctestItem pyspacewar.tests.test_main.doctest_main> <Module test_main.py> <Function test_it> ``` Now, `Module` does collect fixtures. When autouse fixtures are collected, they are added to the `_nodeid_autousenames` dict. Before `ab63ebb3dc`, `DoctestItem` consults `_nodeid_autousenames` at setup time. At this point, the `Module` has collected and so it ended up picking the autouse fixture (this relies on another "accident", that the `DoctestModule` and `Module` have the same node ID). After `ab63ebb3dc`, `DoctestItem` consults `_nodeid_autousenames` at collection time (= when it's created). At this point, the `Module` hasn't collected yet, so the autouse fixture is not picked out. The fix is simple -- have `DoctestModule.collect()` call `parsefactories`. From some testing I've done it shouldn't have negative consequences (I hope).		2024-02-07 21:53:51 +02:00
..
11785.trivial.rst	fixtures: match fixtures based on actual node hierarchy, not textual nodeids	2024-01-08 21:36:51 +02:00
11790.doc.rst	[DOCS] Clarify tmp_path directory location and retention (#11830 )	2024-01-18 07:21:49 -03:00
11801.improvement.rst	nodes: rename `iterparents()` -> `iter_parents()`	2024-01-14 15:17:41 +02:00
11875.bugfix.rst	Catch `OSError` from `getpass.getuser()` (#11875 )	2024-01-28 23:07:18 -03:00
11879.bugfix.rst	Fix an edge case where ExceptionInfo._stringify_exception could crash pytest.raises (#11879 )	2024-01-30 17:20:30 +02:00
11929.bugfix.rst	doctest: fix autouse fixtures possibly not getting picked up	2024-02-07 21:53:51 +02:00
README.rst	Use hyphenated cmdline options in docs (#11490 )	2023-10-10 21:16:24 +00:00
_template.rst	Update CHANGELOG template to put issue links at the start of entries	2018-07-07 11:02:33 -03:00

README.rst

This directory contains "newsfragments" which are short files that contain a small **ReST**-formatted
text that will be added to the next ``CHANGELOG``.

The ``CHANGELOG`` will be read by **users**, so this description should be aimed to pytest users
instead of describing internal changes which are only relevant to the developers.

Make sure to use full sentences in the **past or present tense** and use punctuation, examples::

Improved verbose diff output with sequences.

Terminal summary statistics now use multiple colors.

Each file should be named like ``<ISSUE>.<TYPE>.rst``, where
``<ISSUE>`` is an issue number, and ``<TYPE>`` is one of:

* ``feature``: new user facing features, like new command-line options and new behavior.
* ``improvement``: improvement of existing functionality, usually without requiring user intervention (for example, new fields being written in ``--junit-xml``, improved colors in terminal, etc).
* ``bugfix``: fixes a bug.
* ``doc``: documentation improvement, like rewording an entire session or adding missing docs.
* ``deprecation``: feature deprecation.
* ``breaking``: a change which may break existing suites, such as feature removal or behavior change.
* ``vendor``: changes in packages vendored in pytest.
* ``trivial``: fixing a small typo or internal change that might be noteworthy.

So for example: ``123.feature.rst``, ``456.bugfix.rst``.

If your PR fixes an issue, use that number here. If there is no issue,
then after you submit the PR and get the PR number you can add a
changelog using that instead.

If you are not sure what issue type to use, don't hesitate to ask in your PR.

``towncrier`` preserves multiple paragraphs and formatting (code blocks, lists, and so on), but for entries
other than ``features`` it is usually better to stick to a single paragraph to keep it concise.

You can also run ``tox -e docs`` to build the documentation
with the draft changelog (``doc/en/_build/html/changelog.html``) if you want to get a preview of how your change will look in the final release notes.