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 15:55:11 GMT
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