cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joshua McKenzie (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9160) Migrate CQL dtests to unit tests
Date Mon, 08 Jun 2015 15:46:02 GMT

    [ 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)

Mime
View raw message