You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on this one. It's possible to run pytest in parallel by using the xdist extension and calling up all the cores on your PC. The upside is that it runs way faster, the downside is that the output is very messy and difficult to understand, since the tests do not run in order.
I want to capture the best of both worlds (fast execution from the parallel run, organized output from the single-threaded run) by rearranging the output so that it matches the single-threaded run, with a summary of passes/failures by module, as well as a coverage report at the end.
Is your feature request aligned with the scope of the package?
Yes, absolutely!
No, but it's still worth discussing.
N/A (this request is not a codebase enhancement).
Describe the solution you'd like, or your current workaround.
I've been experimenting with a script, which looks promising. It takes about 1:15 to run, which takes only a quarter of the amount of time it took previously (~4 min). Execution speed on GitHub actions will depend on what they have available, but when doing local development, it runs much faster than before.
(The actual run on local is a lot smoother than this screencast)
Screencast.From.2026-06-30.09-29-31.mp4
Do you have any additional supporting notes?
I'm trying to get the output to closely resemble the single-threaded run. It's getting close, will open a PR once I iron out the differences:
Description
I'm working on this one. It's possible to run pytest in parallel by using the
xdistextension and calling up all the cores on your PC. The upside is that it runs way faster, the downside is that the output is very messy and difficult to understand, since the tests do not run in order.I want to capture the best of both worlds (fast execution from the parallel run, organized output from the single-threaded run) by rearranging the output so that it matches the single-threaded run, with a summary of passes/failures by module, as well as a coverage report at the end.
Is your feature request aligned with the scope of the package?
Describe the solution you'd like, or your current workaround.
I've been experimenting with a script, which looks promising. It takes about 1:15 to run, which takes only a quarter of the amount of time it took previously (~4 min). Execution speed on GitHub actions will depend on what they have available, but when doing local development, it runs much faster than before.
(The actual run on local is a lot smoother than this screencast)
Screencast.From.2026-06-30.09-29-31.mp4
Do you have any additional supporting notes?
I'm trying to get the output to closely resemble the single-threaded run. It's getting close, will open a PR once I iron out the differences:
Would you be willing to contribute this ticket?