[ https://issues.apache.org/jira/browse/JDO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Bouschen updated JDO-71: -------------------------------- Component/s: (was: tck11) > 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 > Fix For: JDO 3 maintenance release 1 > > > 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. - You can reply to this email to add a comment to the issue online.