Hi Steve, One technique which I have used for this scenario is to declare a base class containing the "common" tests. The class should not have the "Test" prefix/suffix as to not be collected by pytest.
Then on the sibling projects, you create a Test subclass from the base class, which in turns makes it collectible by pytest. One point you want to address is how to customize the tests somehow on the sibling project. If you are already using a fixture based system, it is easy to overwrite the fixture in the subclass to return project-specific data which makes sense in that context. I describe this technique in detail in my pytest book, pytest Quickstart Guide if you want more details. Hope this points you in the right direction. Cheers, Bruno. On Mon, Feb 6, 2023 at 1:21 PM Steve <st...@lonetwin.net> wrote: > Hello, > > I'm look for some advice regarding restructuring tests/test layout for an > existing project using pytest. > > Forgive me if this isn't the correct forum for this sort of questions. I'm > sending this here because I felt this doesn't > really qualify as a bug/issue to be raise on github. > > Here's what I am looking for -- I'd like to update / restructure test > within an existing project which initially was > developed as a webapp for a single client/customer but is now being > refactored to allow for a multi-client / multi- > tenent setup. > > The current tests layout is pretty standard with the tests/ directory > living next to the src/ directory and a top-level > conftest.py with fixtures. > > In the new version of the app, we would like to have tests that are: > > a. Common for all deployments and are entirely independent of customer > configuration > b. Common tests per customer configuration (potentially using > parameterised fixtures and/or tests) > c. Customer specific tests (potentially using markers) > > I am curious whether there are any best-practices I could adopt and > pitfalls I ought to be aware of. > > Additionally, any recommendations on tests directory layout and fixture > approaches would also help. > > Ideally, the setup should be flexible enough so that we might to exercise > all the tests (for all customers) or select > all the common tests + parameterized tests + customer specific tests for a > specific customer. > > I'm considering a combination of using custom commandline options[1] and > markers to do this. > > Does a structure like... > > tests > |- conftest.py > |- tests_common/ > | |- tests_parameterized.py > ! |- tests_independent.py > |- customer1/ > | |- conftest.py > | |- tests_speciic.py > |- customer2/ > |- ... > > make sense ? > > I know this is all a bit high-level and vague but I'm trying to learn from > any of you who might have done this before. > So, I recognise and appreciate in advance any time you put into replying > to this. > > cheers, > Steve > > > [1] > https://docs.pytest.org/en/7.2.x/example/simple.html#control-skipping-of-tests-according-to-command-line-option > _______________________________________________ > pytest-dev mailing list > pytest-dev@python.org > https://mail.python.org/mailman/listinfo/pytest-dev >
_______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
