To date, the unit tests proceed mostly by working on a "reference" sqlite database checked into the repository. One of these is "empty", i.e. contains only the dbprocessing table structure but no data.
This PR removes the checked-in empty database. All tests which use an empty database now create the database structure on the fly at the beginning of the test and destroy it at the end.
This PR also checks for PGDATABASE. If it is set, the empty database tests work on an empty Postgresl database instead of sqlite. The database itself must exist, but not the tables. Other tests continue to use sqlite (this is a task for the future). Because of this, a few test failures in Postgresql were also fixed. Only about 20 of the unit tests work on the empty database, but it's a start.
There was some special handling for Postgres testing in the CI suite; that's gone now. The only difference is the setting of the environment variable.
A note on performance: Obviously all this setup/teardown takes some time. Comparison of timing, for running the entire test suite:
Current master (all tests sqlite): 27s
This PR, all tests sqlite: 28s
This PR, some tests Postgres rest sqlite: 48s
So there isn't much of a performance penalty for tests we already had, and the "slow" bit is brand-new tests of the Postgres functionality, which may just plain have more overhead anyhow.
PR Checklist
[X] Pull request has descriptive title
[X] Pull request gives overview of changes
[X] New code has inline comments where necessary
[X] (N/A) Any new modules, functions or classes have docstrings consistent with dbprocessing style
[X] (N/A) Major new functionality has appropriate Sphinx documentation
[X] (N/A, see below) Added an entry to release notes if fixing a major bug or providing a major new feature
[X] New features and bug fixes should have unit tests
[X] Relevant issues are linked in the description (use Closes # if this PR closes the issue, or some other reference, such as See # if it is related in some other way)
At this point I'm not putting something in release notes because it isn't a substantial improvement in Postgres support, but it's a step towards #14. I want to get this in the bag before converting the rest of the tests. (Also make sure the CI works properly.)
To date, the unit tests proceed mostly by working on a "reference" sqlite database checked into the repository. One of these is "empty", i.e. contains only the dbprocessing table structure but no data.
This PR removes the checked-in empty database. All tests which use an empty database now create the database structure on the fly at the beginning of the test and destroy it at the end.
This PR also checks for
PGDATABASE. If it is set, the empty database tests work on an empty Postgresl database instead of sqlite. The database itself must exist, but not the tables. Other tests continue to use sqlite (this is a task for the future). Because of this, a few test failures in Postgresql were also fixed. Only about 20 of the unit tests work on the empty database, but it's a start.There was some special handling for Postgres testing in the CI suite; that's gone now. The only difference is the setting of the environment variable.
A note on performance: Obviously all this setup/teardown takes some time. Comparison of timing, for running the entire test suite:
So there isn't much of a performance penalty for tests we already had, and the "slow" bit is brand-new tests of the Postgres functionality, which may just plain have more overhead anyhow.
PR Checklist
Closes #if this PR closes the issue, or some other reference, such asSee #if it is related in some other way)At this point I'm not putting something in release notes because it isn't a substantial improvement in Postgres support, but it's a step towards #14. I want to get this in the bag before converting the rest of the tests. (Also make sure the CI works properly.)