potiuk commented on issue #42632: URL: https://github.com/apache/airflow/issues/42632#issuecomment-2468060751
> @potiuk Going to attempt this one stage 1: `Providers Non-DB tests` over this weekend, would you have an suggestions or thoughts for this, at present am thinking just have similar setup like task_sdk as mentioned above it is good example direction? Sorry - only see it now (Hackathon) I thought about having completely separate `test-` command for each test type. * `breeze testing core-tests-db` * `breeze testing core-tests-non-db` * `breeze testing providers-tests-db` * `breeze testing providers-tests-non-db` * `breeze testing providers-task-sdk` * `breeze testing system` Then each of the tests will have it's own (specific for the test command) set of test types it can use - core tests will have all the "airflow sub-tests", providers will be able to use `Providers` or `Providers[google]` or `Providers[-amazon,-google]` as they can do today. Task-sdk will not have any type. System tests will have the type based on which provider system tests they are on. Doing it this way has the nice effect that you can easily parallelise them as needed following our paralllel framework but also when you enter breeze with `breeze` command you should be able to run any test or group of tests by just `pytest tests/*` or `pytest providers/tests/*` (both DB and non-DB tests should also work when DB is available). Test type would only be used when you want to run a predefined "set" of tests from outside. I actually have a draft version of this in my local branch, already and I wanted to make a PR today - so if you have not started on it, I might want to set it up for review for you :D -- 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]
