Add functionality to store a copy the current state of the customer database and restore that copy as the primary database to the testing harness. This tests some kinds of malicious customer behavior.
This can be put in temporary storage in integration_tests/gen/ - it is possible to generate an implementation that allows arbitrarily nested storage operations, but I don't think this is necessary to test the behavior we want to verify. I would suggest having a fixed directory for the stored files. An optional feature is to update the Test constructor to enforce (at compile time) a single store/restore operation.
At time of writing, the primary database files that must be saved are integration_tests/gen/customer.{db, db-wal, db-shm}.
Add functionality to store a copy the current state of the customer database and restore that copy as the primary database to the testing harness. This tests some kinds of malicious customer behavior.
This can be put in temporary storage in
integration_tests/gen/
- it is possible to generate an implementation that allows arbitrarily nested storage operations, but I don't think this is necessary to test the behavior we want to verify. I would suggest having a fixed directory for the stored files. An optional feature is to update theTest
constructor to enforce (at compile time) a single store/restore operation.At time of writing, the primary database files that must be saved are
integration_tests/gen/customer.{db, db-wal, db-shm}
.