[
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 (10).
> - 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
