[
https://issues.apache.org/jira/browse/CASSANDRA-9160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14577374#comment-14577374
]
Joshua McKenzie commented on CASSANDRA-9160:
--------------------------------------------
Re: Paxos testing: I'm fine with this change. We need formal paxos / CAS
testing in dtests as well to confirm the multi-node setup is working, but
testing the CQL3CasRequest in isolation makes sense.
bq. A few dtests were exercising the QueryPager functionality of
SelectStatement.execute(). This is not supported by executeInternal(). Should
we add paging to executeInternal()?
This might speak to my ignorance on this area of the code, but is there a
reason you can't use execute() instead of executeInternal() and trust the
QueryPager to make the determination on whether the query is local or not? I
believe that should work fine on single-node unit tests.
bq. We can either commit the tests with the @Ignore annotation or we can remove
them from this patch and add them as a separate patch the the respective
tickets.
I'd say append the tests to the respective tickets so we don't calcify their
interfaces / usage patterns while they're still in progress and leave the
responsibility on the developers to test their code.
bq. Overall I feel we may end up with a gap if we move the CQL tests entirely
to unit tests, specifically the statement execute() methods and the code paths
around these methods (e.g. StorageProxy). Perhaps we should extend CQLTester to
execute over the network rather than only internally or leave some very basic
CQL statements as dtests (one per statement for example).
I think the latter - the 1 dtest per CQL statement type nested under a
test_storageproxy dtest (for example) would be clean and keep those concerns
separated. I think network-based execution unnecessarily expands/blends the
scope of CQLTester.
bq. The rearrangement of converted or existing CQL unit tests is not done yet.
I parked most of the converted tests in a class called "TableTest" unless it
was clear they belonged somewhere else. To rearrange properly I would need some
guidance on a top level structure.
A naive initial look at the file indicates some clear lines of separation:
select tests, create tests, delete tests, dense/compact tests, batch tests,
indexes, and collections are the first ones that pop to me. I'd recommend
organizing the tests in terms of the underlying CQL operations they're testing
and then renaming TableTest to something to indicate the "overflow" nature of
those tests.
I have more reading / reviewing to do on the tests but figured initial feedback
could be helpful.
> Migrate CQL dtests to unit tests
> --------------------------------
>
> Key: CASSANDRA-9160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9160
> Project: Cassandra
> Issue Type: Test
> Reporter: Sylvain Lebresne
> Assignee: Stefania
>
> We have CQL tests in 2 places: dtests and unit tests. The unit tests are
> actually somewhat better in the sense that they have the ability to test both
> prepared and unprepared statements at the flip of a switch. It's also better
> to have all those tests in the same place so we can improve the test
> framework in only one place (CASSANDRA-7959, CASSANDRA-9159, etc...). So we
> should move the CQL dtests to the unit tests (which will be a good occasion
> to organize them better).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
