[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