gh-138013: Move test.test_io to be a module - #138153
Conversation
Sorry, something went wrong.
This sets up for having a test_io._support which contains the I/O mocks for sharing between multiple `io` module test files. Also starts a path for all the `io` module tests to live in a single module for simpler running rather than requiring knowledge of the list of `io` tests which lives in `test_io`. Keeps `python -m test test_io -uall -M8g` and `python -m test.test_io` running the same set of tests as before.
The usual pattern is test.test_support.{topic}_helper, isn't it? Can you elaborate on the proposed _support module? |
Sorry, something went wrong.
|
I was following what I saw in a couple instances (ex. test_string: https://github.com/python/cpython/blob/main/Lib/test/test_string/_support.py, test_zoneinfo: https://github.com/python/cpython/blob/main/Lib/test/test_zoneinfo/_support.py). There's also a couple of support.py (ex. https://github.com/python/cpython/blob/main/Lib/test/test_tkinter/support.py). No idea what is most common or being worked towards as layout. The IO Mocks are only useful for testing the two io module implementations (_io C and _pyio Python) and have specific to io naming patterns that are currently required (ex. MockRawIO -> CMockRawIO, PyMockRawIO + load_tests injection https://github.com/python/cpython/blob/main/Lib/test/test_io.py#L5040-L5077). Things in test.support feel like they're useful for testing multiple Python modules which I don't think these mocks are. |
Sorry, something went wrong.
|
Another approach here would be to make a mock_io.py which mirrors https://github.com/python/cpython/blob/main/Lib/test/mock_socket.py, which would leave test_io.py in the current location (and not need a __main__.py + __init__.py). |
Sorry, something went wrong.
| # * test_memoryio - tests BytesIO and StringIO | ||
| # * test_fileio - tests FileIO | ||
| # * test_file - tests the file interface | ||
| # * test_io - tests everything else in the io module | ||
| # * test_io.test_general - tests everything else in the io module | ||
| # * test_univnewlines - tests universal newline support | ||
| # * test_largefile - tests operations on a file greater than 2**32 bytes |
There was a problem hiding this comment.
Should the modules here be moved into the new package?
Sorry, something went wrong.
There was a problem hiding this comment.
My plan is yes over time, just limiting scope of changes (and PRs) to pieces I'm actively working on changing (Currently Buffered I/O layer). test_bufio I plan to do as part of this overall issue (gh-138013). Not sure how much people rely on the names currently (ex. tracking performance over time by measuring test runtime). Unfortunately there are no benchmarks for CPython I/O in pyperformance currently (is part of my backlog to add).
Sorry, something went wrong.
There was a problem hiding this comment.
The tests can and do move around, we don't make any guarantees here. Performance tests should use the pyperformance suite.
Sorry, something went wrong.
|
If only useful within test_io then a test_io._mock_io or similar seems appropriate, thanks for the explanation. |
Sorry, something went wrong.
|
Could this get a skip news tag? (Test-only change) |
Sorry, something went wrong.
This sets up for having a test_io._support which contains the I/O mocks for sharing between multiple io module test files. Also starts a path for all the io module tests to live in a single module for simpler running rather than requiring knowledge of the list of io tests which lives in a comment in test_io.
Common test invocatoins (ex. python -m test test_io -uall -M8G and python -m test.test_io) run the same set of tests after this change as before.
I copied __init__.py and __main__.py from other python test sub directory instances; happy to tweak if needed.
It is possible to split out the Buffered I/O tests without moving test_io to be a module. In that case still will need a module where the common "mocks" live (My tentative plan is test.test_io._support). I think this sets up for more understandable structure to the io tests overall, but happy to explore the problem space if desired.