That's fine with me, Michael. -- Michelle
Michael Watzek wrote:
Hi Michelle,
I suggest to solve JDO-33 separately and check in the code below
together with the patch for JDO-48. It solves the problem of not
seeing exception traces until the test run has finished. At the time
we solve JDO-33, we can very easily rollback the code below.
Regards,
Michael
Michael,
Please take a look at JDO-33, which discusses the need for a log file
so that the stack traces don't get lost when you kill the test run. I
think it would be good to have the stack traces interleaved with the
test result, rather than all at the end. We also should have a log
file produced by default, rather than having to redirect the test
output to a file. I would also like to see all the information for
part of a test run if I decide to kill it before completion. So
this, in conjunction with a log file, looks good, as long as we don't
see all the stack traces twice.
-- Michelle
Michael Watzek wrote:
Hi,
currently I'm running the TCK with the proposed implementation.
I realized that the TCK output does not show exception traces before
all tests have been executed. Instead, it only prints the execution
status of tests. After all tests have been executed, exception
traces are dumped. For this reason, you have to wait until all tests
have been executed (which takes quite a long time) before you can
start to analyse test failures.
If we catch exceptions in method runBare(), log them, and afterwards
throw them, then we could start analysing failures immediately after
test execution. Clearly, runBare() has a throws clause (Throwable).
Moreover, we can log failures and errors using different log levels.
The runBare() code would look like this:
public void runBare() throws Throwable {
try {
setUp();
runTest();
}
catch (AssertionFailedError e) {
logger.error("Exception during setUp or runtest: ", e);
throw e;
}
catch (Throwable t) {
logger.fatal("Exception during setUp or runtest: ", t);
throw t;
}
finally {
tearDown();
}
}
Does this make sence?
Regards,
Michael
Hi Michael,
On May 25, 2005, at 2:32 AM, Michael Watzek wrote:
Hi Craig,
2) Furthermore, we add 2 methods to class JDOTest which may be
used for registering persistence capable instances and
persistence capable classses. The default implementation of
localTearDown() cleans up all registered persistent data.
We need method names. I'm thinking that we add tear down
instances and classes. So, addTearDownInstance(Object) and
addTearDownClass(Class). Or just registerTearDown(Object) where
the parameter might be a persistent object, an oid, or a class.
What about this:
addTearDownObjectId(Object)
addTearDownInstance(Object)
addTearDownClass(Class)
Ok.
3) We change all tests in order to comply to 1) and 2).
This needs just a bit of extra thought. Some test cases assume
that there are some instances in the database and if there are
none, create some. It's not clear that there is any issue for
these cases, so we should not arbitrarily clean up.
In a first step, I suggest to adapt all life cycle tests. If there
are life cycle tests relying on the execution of other life cycle
tests, then I'll take care that those tests set up the database
properly. If there are non-life cycle tests, relying on the
execution of life cycle tests, then those tests will fail. In that
case, I'll adapt those tests also.
Ok.
Craig
What do you think?
Regards,
Michael
--
-------------------------------------------------------------------
Michael Watzek [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
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!
