Summary

This describes and compares ways of test automation and its data. See also Terminology and pictures at TestMethods.

SeLite testing of DB-driven web apps

It is testing of DB-driven applications, where scripts keep and update a copy of the application’s DB. The scripts themselves (the steps, conditional logic etc.) are not necessarily in a DB. The script-specific input data doesn’t have to be in a DB (but it may be).

The goal

SeLite is for thorough, yet practical testing of DB-driven apps. Your tests

Types of automated testing of DB-driven web applications

This is not Selenium IDE or SeLite-specific, but it only covers what can be done with Selenium. There are a few options, the easiest first:

1. Test uses no DB

This is hardly sufficient as thorough testing. The app DB

The test

Maintenance cost makes this not feasible for long term. Its parts could be reused with SeLite. However, you may want to use different locators, depending on the data schema, page navigation, login functionality. That may be easier when starting from scratch.

2. Web app and its test use the same DB

Like #1, but the test reads from app DB, which

The test

Single source of truth - i.e. same DB used by the app and by the test - causes hidden problems (false positives). The test may succeed, but the data flow has bugs.

The hidden data error may be detected later, but only if

Even worse, the data field (or fields) affected by the hidden bug may be not be verifiable by the rest of the data at all. That’s usually when the DB schema doesn’t cover the history of actions/transactions, or it removes old actions/transactions and it doesn’t cover the intermediary steps. For example, a banking application could keep only the current amount and transaction amounts (credits/debits) for a fixed period, but it doesn’t include amounts current at those transaction dates. If there’s an error in applying a certain type of transaction and it results in an incorrect update of current amount, there’s no way to detect this error - unless you have a separate copy of the data.

See simple online demo as an example.

3. Web app and its test have separate DBs

This explains Overview > Advantages of test data separation. It’s like #2, but the test

If the same error exists in both the app and the test, then it doesn’t get detected automatically. That may be at various levels

SeLite allows us to do this. See also HandlingData.

SQLite side effects of SeLite

SQLite follows SQL standard pretty well, but it may differ to your application’s RDBMS. That can cause false negative errors. See SQLiteSpecifics.