[pytest-dev] Looking for recommendation

Steve steve at lonetwin.net
Mon Feb 6 11:55:09 EST 2023


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 <steve at 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 at python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pytest-dev/attachments/20230206/d2bccca0/attachment.html>


More information about the pytest-dev mailing list