Background

When carrying out automated tests, we need to be able to restore the database to some pristine starting state between tests, to avoid dependencies between tests, introduced by the fact that some tests cause side effects in the DB.

There is an infrastructure for doing this at the moment. This is in class: TikiAcceptanceTestDBRestorer. This allows to restore the DB to a number of different starting states, which we call snapshots.

There are three methods for restoring:

• restoreDB: This is the one that should normally be called. It will try to restore the DB to a given snapshot, by only restoring those tables that have changed since the last restore. This can only work if the the snapshot to be restored. Class TikiAcceptanceTestDBRestorer remembers the last snapshot that was restored, and if it's different from the one we are now trying to restore, it will instead invoke restoreDBFromScratch (see below).
• restoreDBFromScratch: This one restores the complete state, even if only some tables have changed.

This infrastructure currently presents a number of problems.

Prefs not reset after restore

When you restore the DB to some state, the prefs table in the DB gets restored, but the $prefs global variable still remains at it's old value.

So, the methods for restoring the DB should re-initialize the $prefs variable.

In normal Tiki operation, it seems that this is done by script lib/setup/prefs.php. Unfortunately, if I do

include('lib/setup/prefs.php')

in that method, I get an error. It seems that this script cannot be included more than once, or that it can only be included in the context where it is included in normal operation (as opposed to in a testing context).

So, I tried to invoke this instead

$tikilib->get_db_preferences();

and it sort of works. The preferences do get reinitialized, but those preferences which were left to default values in the snapshot end up having a null value. Instead, they should be assigned their default value of 'y' or 'n'. So it seems that get_db_preferences() fails to assign the default values for some reason.

Should use run_file() instead of shell command line

At the moment, the restore methods use mysql command lines to execute sql statements (contained in the db snapshots), in order to restore them.

It would be better if they used the runFile() method of Installer class. That way, the SQL bin directory wouldn't have to be in the path, and also, we would probably get better error reporting if the snapshot contained some errors.

Tiki caches need to be cleared

For certain properties that are queried often (ex: preferences), Tiki keeps then in cache, so as to not read them from SQL tables every time. So, after restore, we need to clear those caches. It think all that is needed is to invoke this:

$cachelib->empty_full_cache();

Prefs still appear unchanged in browser

If you do the following:

• change a preference
• go to the admin panel to display it
• restore the snapshot
• go back to the admin panel

You will find that the preference still appears to be at its changed value instead of the one defined in the snapshot. Under the hood, in the php script, the preference is indeed restored, but if I want this to show up as such in the admin panel, I need to clear the browser cache.

Note that this will only be an issue for Selenium tests, because as I said, under the hood in the php code, the preference is in fact restored.

So, in the case of selenium tests, we should have a way of clearing the browser cache after restoration

Snapshots that are based on a profile

When we want to test a particular profile, we may want to create a snapshot that is created by installing a particular profile onto an empty database.

In those cases, if the profile change, on profiles.tiki.org, there is no way to automatically recreate the snapshot. You have to manually install the new version of the profile, then save the DB to the snapshot.

So... it might be nice to be able to have some snapshots which are created by a script. For example, a php script that would restore an empty DB, then would install a profile, and populate the DB with some data, then save everything to the snapshot.

For those kinds of snapshots, the script create_dump_db_file.pl would invoke the snapshot creation script, instead of just taking the current state of the DB as the snapshot.