potiuk commented on PR #35160:
URL: https://github.com/apache/airflow/pull/35160#issuecomment-1787234830
> One thought. I am wondering if we should not be opinionated here regarding
pytest-xdist. In this PR you leave the choice to the user to use pytest-xdist
or not. But does it make sense to run pytest-xdist with DB tests? It seems not.
Why someone running non DB test would not want to run tests with pytest-xdist?
I might miss some hardware/capacity requirements from pytest-xdist here. In
other words: should not we enable pytest-xdist by default when running non DB
tests and having an option to disable it. Should pytest-xdist parameter be just
ignored when running DB tests
cc: @vincbeck - in the latest version I think I have found the "eat cake and
have it too" solution for that.
* `breeze testing tests` remains a "swiss-army-knife" of running the tests
with multiple switches where you have to specify parallelism and all the flags
manually to select the right tests. It also allows you to run indvidual tests,
folders etc. straight from your host
* But we have also two dedicated new commands which take less parameters but
are dedicated to run db or non-db tests in parallel without passing any special
switch: ``breeze testing db-tests` and ``breeze testing non-db-tests``. Those
commands are also now used in CI to run the tests. And they will choose the
right parallelism mechanism (docker compose for db-tests and `pytest-xdist` for
non-db-tests) - and you have no way to change it.
These two commands have far less options and are much more opinionated and
they only allow you to select test types to run (plus some environmental
things) - no individual tests or folders can be run with them, you also cannot
disable parallelism for them.
I think it is kinda "best of both worlds" - we keep flexibility but also
make it easy for users to run db/non-db tests utilising paralllelism of their
CPUs to maximum (and you can replicate exactly what CI is doing for that).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
