Personally, I like to put both the data cleanup and data
initialization in the setUp() stage. It's sometimes a bit slower, but
if there is faulty cleanup logic in a previous test's tearDown(), it
may affect some random test down the road, and it can sometimes be
very difficult to track down.
TCKs that come out of Sun are especially notorious for this problem :)
On Jan 2, 2007, at 4:07 PM, Craig L Russell wrote:
For What It's Worth:
+1 on the drop-tables feature for OpenJPA. But I would caution
against using it on each test.
Sadly, my experience is that drop-create-tables is 99.9% of the
time taken in a typical test.
The JDO TCK runs hundreds of tests and we drop-create tables only
on demand. The drop-create step takes several minutes compared to a
few seconds to actually run the tests.
After several years of doing this kind of work, I've concluded that
the best practical strategy (we tried beating up the database
vendors to make drop-create as fast as insert/delete rows, to no
avail) is to write your tests such that at the beginning of the
test, you create your test data and at the end of the test, you
delete the test data, leaving the database in an empty state.
JUnit facilitates this by providing a setUp and tearDown. We create
the test data in setUp and delete it in tearDown. Of course, the
tearDown might fail, leaving the data in an unpredictable state,
but it does work 99.9% of the time. That's why we have a common
tearDown that is very carefully implemented to catch exceptions,
retry, etc.
Craig
On Jan 2, 2007, at 12:52 PM, Marc Prud'hommeaux wrote:
Robert-
I completely agree. We usually just build all the tables once and
then just try to make sure all the objects are deleted at the end
of the test, but you are correct that this is sometimes more
cumbersome than it could be. An easy drop-then-create option would
simplify this, although some databases can be notoriously slow
with schema interrogation and manipulation that doing it for each
test might wind up being prohibitively slow.
On Jan 2, 2007, at 3:44 PM, robert burrell donkin wrote:
On 1/2/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:
Shay-
Unfortunately, we don't have any automatic drop-table feature,
but I
agree it would be handy (you might want to make a JIRA report with
the suggestion).
The only other recourse, I think, would be to just manually delete
the database files before running your tests.
support for easy integration testing is one area where i think many
JDO implementations could really improve
it's vital to start with a known database state and clean up after
each integration test. this isn't as easy as it should be when you
have a complex object-relational mapper with extensive caching. a
set
of side doors for integration testing would really help
productivity.
- robert
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
