Spike: Approach to fixtures

Why are we doing this?

opencodelists has a rich set of fixtures but we've identified several issues:

• Test cases are not independent. Whether tests pass or not depends which tests they are run with, due to how the fixtures are created. Some tests don't pass in isolation. See here and here.
  • https://github.com/opensafely-core/opencodelists/pull/2492
  • https://github.com/opensafely-core/opencodelists/issues/2493
• The fixtures define a "universe" of model instances that represent a valid state of the system. These are always set up in full whenever any fixture is requested. Possibly these persisting in memory or the database is related to the tests not being independent. The fixtures expect that tests don't create instances directly, but this is not enforced (and it seems reasonable that tests would want to do that). pytest fixtures usually have a hierarchy where fixtures can depend on other fixtures, but it instantiates exactly what's needed, not other objects. So this works against the framework. It may also be slow.
  • https://github.com/opensafely-core/opencodelists/issues/2523
• The SNOMED fixtures reproduce a small subsection of the real SNOMED heirarchy from a particular version, with real concepts with complicated vocabulary terms and full codes. This could be simpler and easier to grasp if we invented a small tree with simple invented terms and codes.
  • https://github.com/opensafely-core/opencodelists/issues/2524

those fixtures where universe and build_fixtures are called exactly once per test session to load some test data from the file system and put it in the default database, along with some objects created directly (such as the user_without_organisation). The fixtures built by build_fixture all extend universe then return the required object from the database, leaving these objects in the database after any test using these fixtures is executed.

(from https://github.com/opensafely-core/opencodelists/issues/2115#issuecomment-2587843892)

How will we know when it's done?

We have considered and possibly prototyped approaches to the above issues, and raised new ones for future work.

These topics have caused us some issues in the recent past so it could be good to do something on this early in the initiative.

Time box to max 3 days.

Defining delivery tasks guidance