1
votes

I have some code that uses an Informix 11.5 database that I want to run some tests against.

If the tests fail they will often leave the database in an inconsistent state that needs to be manually resolved before the tests can be run again.

I would like to automate this so that the tests do not require manual intervention before running the tests again.

My current solution is to write some code that does the cleanup, but this means the code must be maintained whenever potential new inconsistent states can occur in new features.

The code runs a lot of stored procedures, which themselves often use transactions. As Informix does not support nested transactions I can't just wrap up all the work in one big transaction.

Is there another way to create a checkpoint which I can restore the database back to?

3

3 Answers

1
votes

You could create a virtual machine with an undo disk and after you run the test you can close the virtual machine without saving the changes. It's equivalent to like you never ran the tests!

1
votes

If this is a development only server, how about taking a Level 0 ontape system archive before the test? I think this can be done via the sysadmin functions too (not sure though), so it can be automated. After the tests you just restore the archive.

1
votes

Changing database state - and resetting it back to a known state - is one of the reasons that the Unit Test community spends time and effort avoiding testing against databases. It is a tough problem.

Informix 11.50 does support savepoints; however, it does not support one BEGIN WORK after another without an intervening COMMIT or ROLLBACK.

To the extent possible, have the tests create and load a set of tables with the known data. One way of achieving that is to create a whole new database for the test. However, this is only borderline feasible if you need to test with high volumes of data.

I don't think this issue is in any way unique to Informix - it is a general problem with testing DBMS operations.