[
https://issues.apache.org/jira/browse/CASSANDRA-9210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14512507#comment-14512507
]
Benedict commented on CASSANDRA-9210:
-------------------------------------
Something like (taken from
SelectionOrderingTest.testNormalSelectionOrderSingleClustering):
{code}
ExhaustiveCQLTester tester = new ExhaustiveCQLTester(1,1); // 1 clustering
column (from our perspective), 1 value column (again, from our perspective)
tester.permuteClustering(1,
3).permutePartitionKey(1,2).permuteTypes().permutePartitioners().permuteOrdering();
tester.insert(0,0,0).insert(0,1,1).insert(0,2,2);
tester.select().partitionKey(0).orderBy(true).permuteColumns().verify().row(0,0,0).row(0,1,1).row(0,2,2);
tester.select().partitionKey(0).orderBy(false).permuteColumns().verify().row(0,2,2).row(0,1,1).row(0,0,0);
{code}
Where {{permuteClustering(a,b)}} means that each clustering column we declare
is transformed into between 1 and 3 clustering columns in the real table - and
that the way these are treated are permuted (with 3 columns, we can fix any 2
to be equal and only vary the value of 1, or we can vary the value of two of
them, or all three)
Similarly for {{permutePartitionKey}}
{{permuteTypes}} means to use every possible type for every column; or perhaps
random types
{{permutePartitioner}} should be self descriptive, but means we try the test
for all partitioners
{{permuteOrdering}} means we try the test for all possible ordering
declarations on the table for all clustering columns
{{permuteColumns}} on the select query would permute which columns we actually
return and verify
The upshot is not only a shorter test that covers more ground, but if we were
to add a few extra row inserts it should replace
testNormalSelectionOrderMultipleClustering also, again with more coverage. With
some further tweaking it could cover all of the type conversion function tests
also performed in that unit test, and would also (with tuples implemented in
the type permutation) expand the TupleTypeTest coverage
> CQL Tests Should Operate Over All Types (etc)
> ---------------------------------------------
>
> Key: CASSANDRA-9210
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9210
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
>
> With some refactoring our CQL tests could cover all possible types for a
> given operation, and potentially different positions in the clustering
> component of a primary key, as well as differing adjacent items of data in
> the table being queried.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
