db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Bouschen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (JDO-71) Improve test cases in query.operators package
Date Fri, 17 Jun 2011 16:34:47 GMT

     [ https://issues.apache.org/jira/browse/JDO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Michael Bouschen updated JDO-71:

    Fix Version/s:     (was: JDO 3 maintenance release 1)

> Improve test cases in query.operators package
> ---------------------------------------------
>                 Key: JDO-71
>                 URL: https://issues.apache.org/jira/browse/JDO-71
>             Project: JDO
>          Issue Type: Improvement
>          Components: tck
>            Reporter: Michael Watzek
>            Assignee: Michael Bouschen
>            Priority: Minor
> The general concept of query.operators test cases:
> Class AllTypes maintains arrays for all supported types. The values in these arrays represent
an initial state of the database. There are query tests for all JDOQL query operators. Each
of these tests rely on the initial database state. They perform queries on all supported types
checking the result against expected values.
> The current implementation:
> - The arrays of all supported types have a certain length (10).
> - 10 objects of class AllTypes are made persistent. This is the initial database state.
> - Each quey test performs more or less 30 separate queries on each supported type, and
additionally the same amount of queries for wrapper types. As a very rough estimation, there
may be 2000-3000 separate queries in the operators package.
> - Each of these queries is passed a constant values as parameter and the expected query
result which depends on the certain array length (10). The parameters must match values in
the initial arrays of all supported types.
> Adding addtional test values to the implementation means:
> - Increasing each of the initial arrays by two elements. Regardless, if this makes sense
or not (e.g. boolean arrays).
> - Adapting the expected query result of all separate queries (about 2000 or 3000). This
action has to be taken because the expected query result depends on the certain array length
> - Adding new queries for the new test values.
> Obviously, this is a very big effort for a little functionality enhancement. For this
reason, I propose to change the implementation strategy of the concept with the objective
to make the implementation independent from the initial database state. If we gained this
independency, we could extend the initial arrays without changing the query operator tests.
> The proposal:
> In a first step, we try to reach independeny of the fixed array lengths. Furthermore,
we try to be independent of the constant values for query parameters and the expected query
results. After this step has been taken, all arrays still have the same length (as now), but
we do not have 2000-3000 separate query calls in the code. Instead, we have loops for each
supported type in each query test. Inside each loop, we have exactly one query call. The loops
iterate over the elements of the initial arrays. The parameter values are given by the current
array element. The expected query result can be derived by the current array index.
> The amount of query calls in the code will dramatically decrease. On the other hand,
we can be sure that all values of the initial arrays are queried which is not the case today.
This means that we gain completeness for the query operator tests. Another advantage is the
extensibility of the implementation wrt. the initial arrays.
> In a second step (which we can postpone to the future), we allow the initial arrays to
have different sizes. Thus, a boolean array would have two elements (or three if we would
have NULL tests).
> I believe that the effort to implement the proposal does not exceed the effort to add
test values to the current implementation. It may take about 4-5 days without step two.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message