Build compact yet comprehensive Dev/Test databases.
Enhance development agility: Simplify the creation and management processes of Dev environments,
ensure Dev quality through data integrity and reduce storage capacity requirements.
Bring agility to your testers
The snapshot feature allows testers to compare and restore data during their tests and to incorporate specific data from Prod for debugging purposes.
This module is targeted to testers. It can be implemented as a stand-alone feature for these users, without giving them access to the full generation of Dev databases functionalities
Test-DB main benefits
Teams have tailor-made test databases
A modern DevOps environment requires multiple test databases.
Xcase for i allows to provide each different stakeholder with the test database they specifically need, in terms of structure and data, in order to fulfil their specific testing and development routines. The modifications made on data or structure of their own personal database will not adversely affect others.
Ideally, in the Dev environment 3 types of databases should be made available:
Past: reflecting the current Prod and is needed to debug Prod issues- Present: current Dev database used by the new applications being developed
- Future: This is work in progress on the database not yet released to the developers
Enables them to work on quality data
Providing multiple Test databases having the same content as the Prod database is highly impractical due to space and time constraints.
Test databases produced with Xcase for i will contain only a subset of the data in Prod. Test-DB generates compact, representative and coherent samples, on targeted perimeters (customers, territories, products…), preserving the referential integrity rules defined in the model. The data will be:
- Coherent
- Comprehensive, at record and field Level
- Compact
- Meaningful
Auto-generated extraction scripts
Test-DB allows to easily generate scripts which extract from Prod, compact and coherent sets of data matching your requirements. The scripts are produced using a model without needing to access the data in the Prod environment.
You simply specify which data you need from different tables. For example, a specified list of customers in a CSV file and a random list of 1000 invoices. You can also specify for each relationship if you wish to bring the parents and/or the children. For example, when invoices are selected (explicitly or implicitly) you can decide if the customers to which the invoices refer to and/or the invoice lines should also be extracted.
Test-DB, through his recursion algorithm, will extract all the data according to the rules you set.
Note that the relationships used by Test-DB are the ones defined in the model. The relationships do not need to actually exist in the database.
The extracted data can be anonymized when needed before making it available to Dev using a script generated by Anonymize-DB
Debug Prod with greater agility
When a bug is detected on Prod and you need a specific set of data not currently available in the Test database to replicate the issue in the Dev environment, the testers do not need to wait until data is refreshed from Prod. You can provide the infrastructure operator with a custom extraction script which will represent a complete and coherent set of data. It will be executed very rapidly, as the extracted set of data will usually be small.
Generate synthetic data for new tables
In addition to being able to smartly extract data from Prod, Test-DB can also generate synthetic data. This functionality is needed when new cases not yet present on Prod need to be tested or when newly created tables in Dev need to be populated to be able to properly check the new application features.
Test-DB allows you to automatically add records into a table and to set the content of its columns using a set of a pre-defined methods (Constant/ Increment/ Range/ Expression/ List of Values/ Column from Table/ Column from File/ Foreign Key)
Compare and restore data Snapshots
When an application is tested against a database, it will modify its data. You will probably need to check the application more than once and you will also need to check that the data was changed as expected by the application.
To achieve this, before running the tested application, you can save data from the different affected tables into a snapshot. After running the application, Test-DB allows you to compare the data in the snapshot with the new data. Finally, it allows to restore the data from the snapshot into your database if you wish to run again your tests after the application has been modified.
When defining a snapshot, you can set search criteria for one or more tables and you can also request that all the parent records will be recursively added, thus ensuring integrity.
The same snapshot mechanism allows you to incorporate data made available from Prod for debugging purposes. You can also export snapshot definitions to other stakeholders so they can also update their database.