#37 Added the pytest-backend project #38
Conversation
There was a problem hiding this comment.
Hi @ahsimb,
I really like the plugin, just a few small things you might want to consider.
- Adding an "all" target/option for executing against all backend types
- In combination with 1. changing the default to onprem
My reasoning/thinking behind this is the following:
- Usually the developers want to be quick to run the local tests
- Local testing usally is done with DockerDB (onprem) -> typically faster
- The CI test run will be "statically" configured, adding a flag or option to the config, is a one time effort
- Running only onprem while testing locally needs to be specified on each local test run (tedious)
best
Nico
| backend_options = metafunc.config.getoption("--backend") | ||
| if not backend_options: | ||
| backend_options = [_BACKEND_ONPREM, _BACKEND_SAAS] | ||
| metafunc.parametrize("backend", backend_options) |
There was a problem hiding this comment.
Have you considered, tested or thought about indirect?
https://docs.pytest.org/en/stable/reference/reference.html#pytest.Metafunc.parametrize
There was a problem hiding this comment.
indirect is a way to inject parameters into a fixture from a test. At least that is how I used it. Here I am setting the parameters from a cli.
There was a problem hiding this comment.
Re: default targets. The motivation for including both backends by default was two-fold.
- It makes tests super easy.
- One can argue that the priority is to make sure all tests run on all backends, rather than saving a few seconds of typing. If you need to override the default to include all backends there is a good chance it will be forgotten and the tests on SaaS will never be activated.
There was a problem hiding this comment.
indirectis a way to inject parameters into a fixture from a test. At least that is how I used it. Here I am setting the parameters from a cli.
AFIK in case of the metafunc, it is more about when it is executed if I understand it correctly, TL;DR: collection vs setup - Phase.
pytest-backend/pyproject.toml
Outdated
| pytest-exasol-itde = { path = "../pytest-itde" } | ||
| pytest-exasol-saas = { path = "../pytest-saas" } |
There was a problem hiding this comment.
Are these references to pypi packages?
There was a problem hiding this comment.
These are references to the projects in the same repo.
There was a problem hiding this comment.
I propose to replace these by references to pypi packages.
There was a problem hiding this comment.
That will complicate the process of making changes to the plugins. One would need to change the pytest-itde or pytest-saas, then make a release, then update the pytest-backend and make another release. Is there a particular issue with referencing other projects in the same repo as it is now?
There was a problem hiding this comment.
I am thinking of users using the plugins.
The users will use a pypi reference to backend, I assume.
pypi will not be able to resolve the transitive references with path = "...".
There was a problem hiding this comment.
Will it not? I will do some experiments.
There was a problem hiding this comment.
I built a wheel for the pytest-exasol-backend and installed it in a new venv. All 3 plugins are there, so it seems to work.
pytest-backend/pyproject.toml
Outdated
| pytest-exasol-itde = { path = "../pytest-itde" } | ||
| pytest-exasol-saas = { path = "../pytest-saas" } |
There was a problem hiding this comment.
I propose to replace these by references to pypi packages.
|
I did update the justfile, otherwise the tests wouldn't be running. Now updated the global README.md, but not in great detail, as the plugin structure will likely undergo a significant change. |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
closes #37