Hello Bruno, Thanks for the insightful reply.
That's a neat trick -- depending on pytest's class name collection approach to create a hierarchy for tests. This approach addresses both, the sharing of tests/fixtures as well as having custom tests/fixtures. It might also be possible to be 'smart' w.r.t the parameters in parameterised tests. I'm going through your book now. Thanks again, Steve On Mon, 2023-02-06 at 13:27 -0300, Bruno Oliveira wrote: > 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
