Best way to reset database to known state between FlexUnit4 integration tests?

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 ( http://stackoverflow.com/questions/768944/rollback-database-after-integration-selenium-tests ), but with no satisfactory answers.

Answer 1

I'm dehydrated (my fav excuse for short-comings). So sorry if this answer is too close to the "integration testing service API on the backend" response that you didn't want.

The team that set-up flexUnit 'ages ago' made choices and created solutions based on our architecture, some of which would only apply to our infrastructure. Things to consider: 1) all of our backend methods return the same remotely-mapped class. 2) most all of our methods have an abstracted method that telling the method to (or not to) run a "begin transaction" at the beginning of the method and a "commit transaction" at the end (not sure of your db chunk).

The latter isn't probably the most object oriented solution, but here's what an asynchronous unit-test call does: Every unit test calls the same method-wrapper, and we pass-in the method-name/package-locale, plus the [...]args. A beginTransaction is done. The method is called, passing a false to the method for FE unit tests (to ignore the beginTransaction and commitTransaction lines), everything is run and the main 'response' class is generated and returned to the unit test method. A db-rollback is run and the response is returned to the unit test.

All of our unit tests are based on rolling-back transactions. I couldn't tell you of the issues that they had when setting up that jive, but that's my general understanding of how schtuff works.

Hope that helps. Understandable if it doesn't. Best of luck, --jeremy