db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Bouschen <mbo.t...@spree.de>
Subject Re: New subpackages for TCK query tests
Date Thu, 08 Sep 2005 14:11:50 GMT
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!
> 
> 


-- 
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			

Mime
View raw message