Database Testing

Apart from testing our user interface and API functionality, we need to make sure our databases are working properly.

Databases are fundamental to our website as the communication between us and the user depends on data manipulation on the databases. Users retrieve and store data through the user interface. Hence, frontend testing for the UI is pointless if the backend database doesn’t work properly.

As we’ve learned, there are two types of databases, relational (Oracle, SQL) and non-relational (MongoDB, CouchDB) databases, both of which require different approaches for testing. Visit the Web Development course for a quick refresher on the definitions of the two database systems.

With that in my mind, let’s talk about testing the conventional relational databases.

Relational Databases

A relational or SQL database should be tested for the following properties:

• The database must follow the ACID and CRUD principles.

• Our database must appropriately store and retrieve data. Queries must consistently return the correct results across all users. TOAD and phpMyAdmin are very convenient automated query tools.

• The fields in our database must correctly match the fields in the frontend interface. This is called mapping. DBUnit with Ant tests database-frontend mapping. Field constraints must be consistent at both ends.

• The database must not collapse under load or stress (several multiple read/write operations). HammerDB is a good option to carry out load tests.

• If information in one table is modified, all linked tables must update themselves accordingly. If there is a fault in interconnectivity, the whole site’s functionality is at stake.

Security Testing

• The DB must be resistant against SQL injections. Vega and Wapiti are open source tools suitable for SQL injection testing.