Test Databases

Missing Test Data ? GEDIS Studio generates realistic test data for your databases

All major applications intensively use databases. It is crucial to be able to build test databases to perform both functional testing and performance testing. When testing such applications you face two issues :

1. How can I setup the initial test databases ?
2. How can I build transactions that match both the initial databases content and the testing objectives ?

Test Databases Setup

The purpose of the database setup is to populate the database with the basic data of the test process. The point is not to populate all the tables of a database but the subset required by the test cases.

The main challenge when initializing databases is about realism. Many constraints must be satisfied to obtain realistic and suitable data for testing.

Inner-row constraints Each column is to contain specific data. When filling up tables, you necessary have to respect these domain constraints. For example, a column dedicated to names storage should not contain birth dates. Moreover some columns of a same table can be related. For example, a table dedicated to addresses storage will probably have a country column and a city column. You cannot fill these two columns independently, unless you accept to see e.g. London in the USA.

row-to-row constraints the many rows of a same table can also be related. Consider for example a table containing employees shifts inside a company. You cannot have an employee that was hired after his first move.

table-to-table constraints Many tables refer values stored in another table. For example, you frequently have a "customer" table where an id is associated to a name, address and so on, and an "invoices" table where each row includes the id of the concerned customer.

database-to-database constraints Most of the information system contain duplicated information. Consequently, you have to make sure that your database initialization does not conflict with other databases. For example, you could easily get an employee with different names in different databases.

Transactions generation

Test transactions are used to simulate the interactions between users and databases. Consequently, the content of a test transaction depends on the testing objectives, which seems quite normal.

The main difficulty when generating transactions is, again, to handle the many correlations that exist.

Inner-transaction constraints A transaction contains many fields that can be related. If your transaction simulates the fact that an employee has this address changed, you certainly have some values that specify the new address. Again, you should respect some correlations between, e.g., the country and the city.

Database-to-transaction constraints To be valid, the content of the transaction must concord with the content of the databases. You cannot make an employee move if he does not exist. More tricky, the new address embedded in the transaction must be different from the current address.

Transaction-to-transaction constraints A difficult point is that applying a transaction can modify the content of a database. Consequently, there can exist some complex correlations between simultaneously produced test transactions. For example, if a transaction simulates the fact that an employee quits, the other transactions should not manipulate the same employee.

Automatically generating data for databases testing

Well, this is quite many constraints that you should satisfy before efficiently testing your system. Trying to build test data by hand or without appropriate tools is just unrealistic.

Thanks to its simple design-and-produce approach for creating test data, GEDIS Studio allows you to express the different constraints that your data should respect. You can then populate your databases with huge amounts of realistic data and make sure that your system enforces scalability.