"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 [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
Karan Singh
