|
Home > Archive > Apache JDO Project > June 2005 > JIRA JDO-48
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Michael Watzek 2005-06-06, 7:49 am |
| Hi,
I like to propose a solution for JIRA JDO-48
(http://issues.apache.org/jira/browse/JDO-48).
Actually, JDO-48 describes two issues:
1) Query tests fail cleaning up the database because of a foreign key
constraint violation. The reason is that HollowInstanceMaintainsPK does
not clean up the database.
2) Different TCK tests have different strategies for clean up.
This proposal fixes issue 2) and, as a side effect, issue 1) also.
Current status:
Class JDOTest is the super class of all TCK tests. Amongst others, this
class defines methods setUp() and tearDown(). Method setUp() creates the
PMF instance. Method tearDown() closes the PM instance (created by
tests) and it closes the PMF instance. Furthermore, method tearDown()
implements the semantics that takes care for throwing the right
exception in case of tests and/or tear down failures: Exceptions during
tear down do not affect the test result in case of test failures. In
such cases, method tearDown() logs exceptions. However, if tests succeed
and tearDown() throws an exception then that exception determines the
test result.
Problem:
Some tests override method tearDown() cleaning up the database, some
tests clean up the database inside the test methods (testXXX).
Proposal:
The objective of this proposal are:
1) Tests should not need to override method tearDown() as the semantics
is not trivial and error-prone. Instead, tests have hooks into setUp()
and tearDown(). There, they may allocate/release resources and/or data.
2) Tests may register created (persistent) data. That data is cleaned up
automatically during tearDown().
Solution:
1) We add 2 methods to class JDOTest localSetUp() and localTearDown().
These methods are called by setUp() and by tearDown(). They are hooks
into the two methods and they may be overridden by subclasses.
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.
3) We change all tests in order to comply to 1) and 2).
Obviously, issue 3) is most time-consuming. For this reason, I suggest
to solve 1) and 2) in a first step. In a second step, we solve issue 3)
per TCK package, e.g. starting with "org.apache.jdo.tck.lifecycle".
What do you think?
Regards,
Michael
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
| |
| Michelle Caisse 2005-06-06, 7:49 am |
| Michael,
This looks great. Thanks!
-- Michelle
Michael Watzek wrote:
> Hi,
>
> I like to propose a solution for JIRA JDO-48
> (http://issues.apache.org/jira/browse/JDO-48).
>
> Actually, JDO-48 describes two issues:
>
> 1) Query tests fail cleaning up the database because of a foreign key
> constraint violation. The reason is that HollowInstanceMaintainsPK
> does not clean up the database.
>
> 2) Different TCK tests have different strategies for clean up.
>
> This proposal fixes issue 2) and, as a side effect, issue 1) also.
>
> Current status:
>
> Class JDOTest is the super class of all TCK tests. Amongst others,
> this class defines methods setUp() and tearDown(). Method setUp()
> creates the PMF instance. Method tearDown() closes the PM instance
> (created by tests) and it closes the PMF instance. Furthermore, method
> tearDown() implements the semantics that takes care for throwing the
> right exception in case of tests and/or tear down failures: Exceptions
> during tear down do not affect the test result in case of test
> failures. In such cases, method tearDown() logs exceptions. However,
> if tests succeed and tearDown() throws an exception then that
> exception determines the test result.
>
> Problem:
>
> Some tests override method tearDown() cleaning up the database, some
> tests clean up the database inside the test methods (testXXX).
>
> Proposal:
>
> The objective of this proposal are:
>
> 1) Tests should not need to override method tearDown() as the
> semantics is not trivial and error-prone. Instead, tests have hooks
> into setUp() and tearDown(). There, they may allocate/release
> resources and/or data.
>
> 2) Tests may register created (persistent) data. That data is cleaned
> up automatically during tearDown().
>
> Solution:
>
> 1) We add 2 methods to class JDOTest localSetUp() and localTearDown().
> These methods are called by setUp() and by tearDown(). They are hooks
> into the two methods and they may be overridden by subclasses.
>
> 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.
>
> 3) We change all tests in order to comply to 1) and 2).
>
> Obviously, issue 3) is most time-consuming. For this reason, I suggest
> to solve 1) and 2) in a first step. In a second step, we solve issue
> 3) per TCK package, e.g. starting with "org.apache.jdo.tck.lifecycle".
>
> What do you think?
>
> Regards,
> Michael
| |
| Craig Russell 2005-06-06, 7:49 am |
| | |
| Michael Watzek 2005-06-06, 7:49 am |
| Hi Craig,
>
>
> 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)
>
>
>
> 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.
What do you think?
Regards,
Michael
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
| |
| Craig Russell 2005-06-06, 7:49 am |
| | |
| Michael Watzek 2005-06-06, 7:49 am |
| 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:
>
>
>
> Ok.
>
>
>
> Ok.
>
> Craig
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
| |
| Craig Russell 2005-06-06, 7:49 am |
| | |
| Michelle Caisse 2005-06-06, 7:49 am |
| 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
>
>
>
>
| |
| Michael Watzek 2005-06-06, 7:49 am |
| 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
[vbcol=seagreen]
> 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:
>
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
| |
| Michelle Caisse 2005-06-06, 7:49 am |
| 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
>
>
>
|
|
|
|
|