Question

Background:

I have a Flex web app that communicates with a Java back-end via BlazeDS. The Flex client is composed of a flex-client module, which holds the views and presentation models and a separate flex-service module which holds the models (value objects) and service objects.

I am in the process of writing asynchronous integration tests for the flex-service module’s RemoteObjects using FlexUnit4. In some of the tests, I modify the test data and query it back to see if everything works (a technique shown here: http://saturnboy.com/2010/02/async-testing-with-flexunit4)

Question:

How do I go about resetting the database to a known state before each FlexUnit4 test method (or test method chain)? In my Java server integration tests, I did this via a combination of DBUnit and Spring Test’s transactions — which rollback after each test method. But these Flexunit integration span multiple requests and thus multiple transactions.

Short of implementing an integration testing service API on the backend, how can this be accomplished. Surely others have run into this as well? Similar questions have been asked before ( Rollback database after integration (Selenium) tests ), but with no satisfactory answers.

Answer 1

There are several options:

1. If you use sequences for primary keys: After the database has been loaded with the test data, delete the sequence generator and replace it with one that starts with -1 and counts down. After the test, you can delete objects with a primary key < 0. Breaks for tests which modify existing data.

   A similar approach is to create a special user or, if you have created timestamp columns, then the initial data must be before some date in the past. That needs additional indexes, though.

2. Use a database on the server which can be quickly wiped (H2, for example). Add a service API which you can call from the client to reset the DB.

3. Add undo to your web app. That’s quite an effort but a very cool feature.

4. Use a database which allows to move back in time with a single command, like Lotus Notes.

5. Don’t use a database at all. Instead write a proxy server which will respond to the correct input with the correct output. Add some code to your real server to write the data exchanged into a file and create your tests from that.

   Or write test cases which run against the real server and which create these files. That will allow you to track which files change when you modify code on the server or client.

   On the server, write tests which make sure that it will do the correct DB modifications.

6. Similar to “no database at all”, hide all code which accesses the DB in a DB layer and use interfaces to access it. This allows you to write a mock-up layer which behaves like the real database but which saves the data in memory. Sounds simple but is usually a whole lot of work.