Currently, the test fromework tests everything up to generation of a migration. That is: desugaring, detection, transformation, webdsl m3 translation, loading and normalizing of webdsl applications and SQL migration generation. The execution of the SQL migration scripts is left untested, as it requires a database (and possibly data) to check. I have searched for syntax checking solutions, but these appear hard to find. Considering it is the only weak (untested) link remaining in Acoda and one which frequently appears buggy, it should be tested.

Find a way to use some type of temporary database to perform migration tests on. Tests need to be executable on any system (particularly on Hydra), hence it should have little restrictions on the available data storage possibilities.

Submitted by Sander Vermolen on 1 October 2010 at 15:29

I added migration tests to Acoda’s test framework:

Originally, the test set was used in detection, desugaring, SQL generation and some other minor components. The generated SQL remained untested. I now added code to the test framework, which initializes a database schema for the test case and executes the migration. Thus, it tests the schema generation as well as the migration. Not so much for correctness yet, that is a next step, but at least it tests whether all generated SQL can be run.

The added test functionality requires mysql programs, a mysql database called acoda_test and a mysql user called acoda using password acoda. This is not available on Hydra yet, as such it will most likely fail. I plan to add a check to see whether mysql testing can be performed and skip it otherwise.

As a side remark: it already uncovered some (minor) bugs, so it seems to be working.