There is currently no "migration test" (=verifying the PHP response is identical to the Python response, minus documented changes), because the test infrastructure makes this hard. Since the PHP calls directly
mutate the database, we need to ensure we can recover the old database state after the test. We can not generally do this for the dataset status update call, as for that we need to know the initial state of the database (e.g., activating a dataset can be achieved by either adding an active row or removing a deactivated row).
While we do know the database state, we would need to hard-code that information into the tests. A better approach would be to start up a new separate database container for PHP (from the same image). This would negate the need to "undo".
A second issue that arises because of ordering:
if we call PHP first, the database is changed and the Python response would be different
if we call Python first, it opens a transaction for the duration of the test, which blocks execution of the query issued from PHP, which halts the test.
This too is mitigated by introducing a second database. The only potential risk you introduce is to be working on different databases. Overall though, the effect of this should be rather minimal as the database would be effectively reset after every individual test.
Spinning up an instance for each test does likely add significant overhead. I would have to measure, but I would expect 1~2 seconds per test locally.
The second database could also just be a SQLite database. At least for this test, the required tables and populated data are manageable and hopefully is much faster than starting a container. Though I think it might not work as neatly when we requiring different data across many tables (though if neatly organized into different fixtures, maybe that works OK).
There is currently no "migration test" (=verifying the PHP response is identical to the Python response, minus documented changes), because the test infrastructure makes this hard. Since the PHP calls directly mutate the database, we need to ensure we can recover the old database state after the test. We can not generally do this for the dataset status update call, as for that we need to know the initial state of the database (e.g., activating a dataset can be achieved by either adding an
activerow or removing adeactivatedrow). While we do know the database state, we would need to hard-code that information into the tests. A better approach would be to start up a new separate database container for PHP (from the same image). This would negate the need to "undo".A second issue that arises because of ordering:
This too is mitigated by introducing a second database. The only potential risk you introduce is to be working on different databases. Overall though, the effect of this should be rather minimal as the database would be effectively reset after every individual test.
Spinning up an instance for each test does likely add significant overhead. I would have to measure, but I would expect 1~2 seconds per test locally.
The second database could also just be a SQLite database. At least for this test, the required tables and populated data are manageable and hopefully is much faster than starting a container. Though I think it might not work as neatly when we requiring different data across many tables (though if neatly organized into different fixtures, maybe that works OK).