|
Home > Archive > Apache JDO Project > September 2005 > New subpackages for TCK query tests
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
New subpackages for TCK query tests
|
|
| Michael Bouschen 2005-09-07, 5:45 pm |
| 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.
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
- result testing query result handling
- sql testing SQL queries executed from a Query instance
- delete testing delete queries
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?
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 2005-09-07, 5:45 pm |
| | |
| Michael Bouschen 2005-09-08, 5:45 pm |
| Hi Craig,
> Hi Michael,
>
> On Sep 7, 2005, at 6:38 AM, Michael Bouschen wrote:
>
>
>
> 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.
>
>
>
> include newQuery, which are really PersistenceManager API but probably
> belong here.
Yes, I agree.
>
>
>
> Including resultClass tests.
Yup.
>
>
>
> Good.
>
>
>
> 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.
>
>
>
> 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
>
>
> 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
| |
| karan malhi 2005-09-08, 5:45 pm |
| "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,
>
>
>
> 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.
>
>
>
> Yes, I agree.
>
>
>
>
> Yup.
>
>
>
> Agreed. We have four assertions for delete queries, so they could go
> into api.
>
>
>
> 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.
>
>
>
> 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
>
>
>
--
Karan Singh
|
|
|
|
|