db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michelle Caisse <Michelle.Cai...@Sun.COM>
Subject Re: JIRA JDO-48
Date Wed, 25 May 2005 18:05:09 GMT
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                  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!
>>>
>>>
>>>
>>>
>>>
>
>


Mime
View raw message