You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following from discussion in #2117 it seems like using the test fixture data as dummy data for development is an attractive alternative to using a copy of the production database.
The OpenCodelists tests contain a number of fixtures (e.g. here but NB there exist fixtures in other apps) which are small, internally consistent, comprehensive (in terms of coding systems and site features), and devoid of user PII.
The comprehensiveness of these test fixtures ensures adequate test coverage, but also makes them potentially useful for interactively and iteratively developing new features/fixing bugs.
Being PyTest fixtures, these are loaded into in-memory sqlite databases which are created at the beginning of a test session and destroyed at the end. To be useful as development data, a process to load them into persistent on-disk sqlite databases would be required.
Directly calling the test fixtures outside of a PyTest test is not permitted so some other way around this may be required (see this comment for relevant prior art in ehrQL).
This work may or may not be affected to changes to our test database configuration required for upgrading to Django 5.1.x in #2115
The text was updated successfully, but these errors were encountered:
Following from discussion in #2117 it seems like using the test fixture data as dummy data for development is an attractive alternative to using a copy of the production database.
The OpenCodelists tests contain a number of fixtures (e.g. here but NB there exist fixtures in other apps) which are small, internally consistent, comprehensive (in terms of coding systems and site features), and devoid of user PII.
The comprehensiveness of these test fixtures ensures adequate test coverage, but also makes them potentially useful for interactively and iteratively developing new features/fixing bugs.
Being PyTest fixtures, these are loaded into in-memory sqlite databases which are created at the beginning of a test session and destroyed at the end. To be useful as development data, a process to load them into persistent on-disk sqlite databases would be required.
Directly calling the test fixtures outside of a PyTest test is not permitted so some other way around this may be required (see this comment for relevant prior art in ehrQL).
This work may or may not be affected to changes to our test database configuration required for upgrading to Django 5.1.x in #2115
The text was updated successfully, but these errors were encountered: