Andrés González wrote:
mess with the database and leave it as it was before running the tests (now i'm doing the lazy-option: at the end of each test i delete everything and restore some "initial" info).
Going off-topic slightly, the Interface21 guys have what I think is a very nice approach to this which is arguably even lazier. They have their JUnit tests set up to wrap each database-oriented test in a transaction and roll it back afterwards (whether it succeeds or fails.) There is thus never any need to do a "set up and tear down the test data" step. You can even start with a snapshot of your live data if your tests require something more complex than can easily be generated programmatically.
I'm not sure whether their implementation is freely available (I got it when I went to one of their Spring seminars; it's not part of the framework) but the idea is pretty straightforward: just subclass TestCase to do the transaction stuff in its setUp/tearDown methods, and your actual tests subclass that new class so they don't have to worry about the details. Your wrapper class can of course also take care of supplying the test classes with appropriate database handles.
I used to use DBUnit to do the "set it up each time" approach, but I've found this approach much more efficient both in terms of test execution time and test writing time. You can combine the two approaches if you need to have special test cases that are mutually exclusive; just let the rollback restore your test data to its known initial state after you've deleted/inserted your test rows.
-Steve _______________________________________________ Rife-users mailing list [email protected] http://lists.uwyn.com/mailman/listinfo/rife-users
