db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From karan malhi <karan.ma...@gmail.com>
Subject Re: New subpackages for TCK query tests
Date Thu, 08 Sep 2005 14:29:42 GMT
"This might not deserve another package. There are not that many tests 
here. So I'd guess that delete could go into the api package.

Agreed. We have four assertions for delete queries, so they could go 
into api. "

Wouldnt it be more intuitive if we put the delete queries in  a seperate 
package?


Michael Bouschen wrote:

> Hi Craig,
>
>> Hi Michael,
>>
>> On Sep 7, 2005, at 6:38 AM, Michael Bouschen wrote:
>>
>>> Hi,
>>>
>>> Michael W. and I started looking into JDO assertions testing JDO 
>>> query features that have been added with JDO2. None of them are 
>>> implemented yet, so we will have to add a couple of new query test 
>>> classes.
>>
>>
>>
>> It might be more than a few, like a dozen or so? 
>
>
> I'm afraid there are more than just a dozen :-). We have 58 new query 
> assertions and usually we have a test class per assertion.
>
>>
>>>
>>> Today the query package org.apache.jdo.tck.query includes 65 test 
>>> classes and we would need to add a couple of more to test the JDO2 
>>> query features. We think this is too much for one package, so we 
>>> propose adding some subpackages to org.apache.jdo.tck.query:
>>> - api testing the Query API methods
>>
>>
>>
>> include newQuery, which are really PersistenceManager API but 
>> probably belong here.
>
>
> Yes, I agree.
>
>>
>>> - result testing query result handling
>>
>>
>>
>> Including resultClass tests.
>
>
>
> Yup.
>
>>
>>> - sql testing SQL queries executed from a Query instance
>>
>>
>>
>> Good.
>>
>>> - delete testing delete queries
>>
>>
>>
>> This might not deserve another package. There are not that many tests 
>> here. So I'd guess that delete could go into the api package.
>
>
> Agreed. We have four assertions for delete queries, so they could go 
> into api.
>
>>
>>> Some of the existing test cases need to be refactored into the api 
>>> package. Should we keep the remaining tests in 
>>> org.apache.jdo.tck.query or should we add another package (e.g. 
>>> language) for these?
>>
>>
>>
>> There's already an operators package. Maybe we should add a jdoql 
>> package with the language features like operators in subpackages? How 
>> many language features have so many tests that it makes sense to 
>> split out? Grouping maybe. Aggregates maybe.
>
>
> Sounds good. So we start with query.jdoql and query.jdoql.operators 
> and we might add another jdoql subpackage there is another functional 
> area with an significant amount of test classes.
>
>>
>> What about String queries? My inclination would be to test String 
>> queries alongside language features, so the test case would have each 
>> feature tested three ways: setFilter, String query, and metadata 
>> query. That might make more sense than having the same feature appear 
>> in three different tests, especially since if the language feature is 
>> broken, it's broken three ways in one test and not broken in three 
>> tests.
>
>
> I agree that all the new classes testing language features should test 
> the same query created in two ways: programmatic using the API methods 
> (setFilter, declareImportes, etc.) and the single string query.
>
> We have a couple of assertions about queries specified in the 
> metadata, so this should be covered there. Once the Query instance is 
> created it does not make any difference whether the single came from 
> the metadata or was directly passed to the pm.newQuery call. So I have 
> the feeling it does not add much value if the new language query tests 
> also include a metadata single string query.
>
> Regards Michael
>
>>
>> Craig
>>
>>>
>>> Regards Michael
>>> -- 
>>> Michael Bouschen        Tech@Spree Engineering GmbH
>>> mailto:mbo.tech@spree.de    http://www.tech.spree.de/
>>> Tel.:++49/30/235 520-33        Buelowstr. 66            
>>> Fax.:++49/30/2175 2012        D-10783 Berlin           
>>>
>>
>> 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!
>>
>>
>
>

-- 
Karan Singh


Mime
View raw message