[
https://issues.apache.org/jira/browse/CASSANDRA-19978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887027#comment-17887027
]
João Reis commented on CASSANDRA-19978:
---------------------------------------
{quote}I dont think sharing cluster across tests is a good idea. cassandra
dtests repository is spinning cluster every single test method if it is
necessary. In majority of cases, we will be starting 1 node cluster anyway.
{quote}
Hmm this would make it very cumbersome to run the entire test suite, even
starting a 1 node cluster takes some time. I think we should have a goal of
being able to run the full test suite in less than 30 minutes (maybe even 20).
I'm not sure how many tests we currently have but if we launch a cluster for
every single test the test run time will increase very rapidly. Other drivers
try to share clusters within a group of tests and it works very well, new
keyspaces and tables can be created per test (with randomly generated strings)
when needed to ensure some isolation.
{quote}To be fair, on the other hand, a user needs Docker so we go Docker vs
Python + CCM. Not sure what is better.
{quote}
Docker is definitely better because most devs already have it on their dev
environment anyway. But it really feels like it is the only benefit we could
get while losing some things so I don't think the trade-off is worth it
personally.
{quote}gocql driver is Go-first project so I do not know why we should rely on
CCM.
{quote}
CCM is what all drivers use for tests that require real clusters, it provides a
lot of things out of the box. It makes it super easy to manage multi node
clusters and dynamically start/stop and add/remove nodes that is needed for
certain test cases. It also provides a very easy way to customize the C*
config. Additionally, it provides the huge benefit of being able to run a C*
version from a git ref so it's super easy to verify that the driver is working
correctly with a specific C* build that is not GA, we've actually done this in
preparation for certain C* releases in the past on the DataStax drivers.
If we decide that testcontainers is a better solution than CCM for driver tests
then logically that would apply to all drivers and all drivers should move to
that, I don't think it makes much sense to have all drivers use CCM instead of
one.
The other drivers rely on Simulacron for tests that don't require a real
cluster, this makes it very easy to keep the test suite run time small. However
Simulacron is a Datastax project and not very well maintained atm so I think it
would be hard to convince folks to adopt it and I won't push for it.
{quote}Benefit of not being on CCM is that a developer does not need to mess up
with Python + CCM.
{quote}
I do agree that requiring a user to deal with ccm and python to run the driver
tests is far from ideal... Maybe we could have an integration test framework
that can work with both CCM and Testcontainers and any test that needs multi
node clusters or customizing C* config would be skipped if the "backend" is set
to testcontainers? CCM would be used in CI and would be our standard way of
certifying a driver release since it runs all tests but the "testcontainers"
backend could be used by contributors that don't want to deal with ccm? This
would be a lot of work though, and possibly cumbersome to maintain long term.
> Rewrite integration test setup in Go
> ------------------------------------
>
> Key: CASSANDRA-19978
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19978
> Project: Cassandra
> Issue Type: Task
> Components: Client/gocql-driver
> Reporter: João Reis
> Priority: Normal
>
> {quote}Currently integration tests use ccm to setup a Cassandra cluster for
> testing.
> It is not easy to simulate things like topology changes, nodes joining,
> leaving, re-joining with a different IP address, etc.
> We could rewrite integration test runner using Docker API directly or using a
> library like testcontainers-go.
> {quote}
>
> https://github.com/apache/cassandra-gocql-driver/issues/1686
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
