I’ve written several unit tests for an already existing DatabaseOpenHelper class. I covered the creation scenario and migration from old schema to new one. Unfortunately, I don’t feel that my tests are good. For example, for DB creation I check that SQLiteDatabase. execSQL() was called three times (we have three tables so far) and check that query string is in set of specified SQL strings.
The issue so far – if someone changes order of columns the test will fail. Probably this is OK.
But what are other ways of SQL schema unit testing? Or don’t you have unit tests for that, and rely only on the integration one?
1
Instead of verifying that
- colum1 is name,
- colum2 is birthday,
- colum3 is ….
i would just test if these colums exist after upgrade.
To do this I would create an integration test that
- starts with a databasefile which has old database version,
- run the updater and then
- execute a sql-select for every table with a all fields.
Example:
- select name, birthday, telefonnumber from customer
- select orderid, orderdate, customerid from order
Test-Success means there is no database-exception for unknown table or field.
[Update 2.2.2013]
Unittesting the DatabaseOpenHelper (Unittest=Testing in isolation) would requre to test without a real database and verifying that the database update script is valid or at least contain all neccessary fields/tables. In my opinion this is to much work. Integration testing with a real database is much easier.
1
A schema comparison could be useful. You have one database that is known to have the “correct” schema. This could be a copy of the development database after a code freeze. Then create your new database. Use a comparison tool to identify any differences between the 2 databases. Microsoft Visual Studio comes with a schema comparison tool. There are several 3rd party tools. I use my own custom-built comparison tool which lists all the differences in 2 databases.
Alternatively you could simply check if your schema creation scripts execute without error. The scripts ARE the schema definition, so in theory you do not need to compare or check anything other than the fact they executed without error.
But in my experience people introduce changes to a database without scripting them. A comparison tool can catch these unscripted changes.
1
When I faced this problem the road I walked sent me right into checking the database definition sentence with the expected one. This was broadly comparing a string with another one.
I recognized how absurd this was when I found myself getting the sentence from the code execution, checking it manually in notepad and inserting it in the test every time I made a change in the schema.
Right now I use integration test for the schema validation. In my case this involves exercising all persistance related operations (excluding performance-related ones).
I do not like the time required for this approach, but it is the best fair approach I have found.
1