Summary

This explains how a web app and Selenese scripts can operate with separate databases (TestMethodsTheory > Web app and its test have separate DBs).

Script data lifecycle

Initially, the script DB is a copy of the web application’s DB (possibly with less tables and columns or records). For each logical step, the script triggers an operation in the browser and it also updates its own DB to reflect that operation. Updates in script DB don’t need to be exactly same as updates in app DB. The script only updates columns/tables that we use for validation. The script compares the result page of the web app to the updated script data.

If the app or the script fails, their databases can get out-of-sync. That causes non-obvious knock-on errors later. That should normally happen only if

Re-loading the data

If the script and web app data is out of sync, you we want to re-load it. SeLite doesn’t automate this. If we (ever) automate it, then we want it to

If the error was outside of both the app and the script, and the script can detect that, it could

Otherwise, the error is in the app or in the script. Re-loading the data won’t fix the script neither the application. It is beneficial, however, when user needs to use other parts (before the failed part, whether of the app or the script, gets fixed).

We can re-load

There will also be a need to reload both DBs, even if everything is healthy (app and script are OK and both DBs in sync). That’s when we reach designed limits of the application. For example, the app may limit the number of submissions per user per day without a way to remove them through the application’s web interface.

Loose script data

Some fields are difficult to replicate from app DB to script DB during the runs. Those are

IDs of new records

Many of the following notes are for Postgres or SQLite. However, some notes and most of the ideas are not DB-specific.

Navigating by record IDs is needed e.g. for security testing to ensure that a user can’t get inappropriate access. In such a case the script can’t navigate through the web app to the forbidden page, so it needs to know the ID value to generate the link (to verify that the access is denied).

When the script creates a new record in its DB, it needs to set its ID to reflect the ID in the app DB. Methods:

Non-trivial references

Non-trivial references are based on

If you want to validate them, you need to make the script capture those values and store them in script DB whenever they get created/updated in the app.

Reloading databases and creating/updating user passwords

See SettingsInterface > Reloading databases. If your scripts create/update user passwords, see GeneralFramework > Preserving special values in script DB.

External data

Applications often use data sources outside of their DB (e.g. web services). If

then have the script use that data (via a back door). That’s fairly easy between SeLite and webservices. However, if the data source is a of some other type, then you’ll need either (in order of complexity)

If the app writes to the external data source (directly or indirectly), then treat it like another app DB. Have your script use (read and update) a writable copy of that external data (transformed to SQLite). You’ll need script(s) to populate those table(s), so you can change and re-load the copy in future.

No column name toString

You must not have a DB column with name toString. That’s because Javascript objects representing DB records have method toString() for convenience.