db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Watzek <mwa.t...@spree.de>
Subject Re: JIRA JDO-48
Date Wed, 25 May 2005 17:42:41 GMT
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                  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
>>> 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/
-------------------------------------------------------------------

Mime
View raw message