In light of the warnings against queries using the ORM before the apps are ready, we decided to go the route of doing it all in the settings as well. While it does result in settings code that is more brittle than desired, it has the upside that any broken code is made painfully obvious to the developer as the server won’t even get to the point of throwing hundreds of failed tests due to missing database connections.
The process is now this:
- Set default values for non-essential settings
- Load custom values for settings, which in turn:
- Check if the executed command is the test command.
- Set the default database to either a SQLite test database or a regular database depending on the step above
- Set custom values for various settings. A template is provided which corresponds to a dev environment, that does not allow outside access
- Check if all essential settings have been provided by the custom settings
- Load project database connections by either:
- If it is a test command: Crawling through fixtures to check which projects are required and add SQLite database connections for all found
- If not: Check the default database for connection details to the project databases and add them
This process should have the desired behaviour for all four combinations of dev/prod environments and test/live command. I don’t see how it could happen that production data ends up in tests.