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!
--
Michael Bouschen [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
