Hi Michael, Brian,
If we clean up in setUp, who cleans up after the last test? The
information about what needs to be cleaned up is lost at the end of the
test run.
-- Michelle
Michael Bouschen wrote:
Hi Brian,
I see your point, especially checking the datastore state afterwards
is an issue with the current way of cleaning up. The reason for doing
the cleanup in tearDown was that the test knows which instances it
created, so it knows what needs to be cleaned up. In setUp you do not
know what the previous test left behind.
Maybe we should support both: cleanup in setUp or in tearDown and let
the user decide by setting properties. I could imagine properties like
CleanupAtSetup and CleanupAtTeardown both having values yes/no and
reasonable defaults. If we go for supporting cleanup in setUp methods
addTearDownObjectId and addTearDownInstance do not make sense anymore
and should be removed.
Regards Michael
Minor point, but I would suggest doing it in setUp() for a couple
reasons:
* You know datastore is in good state before test runs instead of after
* You can examine datastore state afterwards to double check things
manually
* If things go wrong during the test, the evidence isn't erased
On Aug 9, 2005, at 5:51 PM, Craig Russell wrote:
Hi,
I'm thinking a better way of cleaning up might be:
Extent toBeDeleted = pm.getExtent(parameterClass, false);
Query toBeDelete = pm.newQuery(parameterClass, toBeDeleted);
toBeDelete.deletePersistentAll();
This doesn't require that the query be executed except for the
purposes of calling the jdoPreDelete callback, which is not an
issue in the TCK.
Does JPOX support this? Would it help (I'm thinking of the issue
with CompletenessTest not cleaning up because of issues with
loading the instances).
Craig
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!
