On Thu, Sep 1, 2011 at 9:08 AM, Eric Evans <eev...@acunu.com> wrote: > On Wed, Aug 31, 2011 at 10:58 PM, Jonathan Ellis <jbel...@gmail.com> wrote: >> On Wed, Aug 31, 2011 at 4:24 PM, Eric Evans <eev...@acunu.com> wrote: >>> CASSANDRA-2936 is in progress (patches attached), but is there any >>> reason not to get started with the Python driver now? >> >> Heads up that test/system/test_cql.py depends on the Python driver. >> It should probably be moved to the Python driver's test suite. (Which >> then needs the same kind of "start a Cassandra server" ability that >> the Cassandra system tests have.) > > I posed a similar question about the JDBC driver in CASSANDRA-2936. > > Should these tests be considered functional tests of Cassandra, and > left be left where they are? I know that was my intention WRT > test_cql.py (the driver itself has a few tests of its own that do not > require a server). > > I guess I don't have a strong opinion either way, though it seems > easier to say that Cassandra's tests will require you to have a driver > installed, versus having to configure the build/test of a driver to > point to a Cassandra tree.
No opinions on this? To summarize, the options as I see them are: 1. Keep the tests that query Cassandra, as-is, with the drivers they use. 2. Leave the tests that query Cassandra with Cassandra, (i.e. consider them Cassandra tests). 3. Keep the tests that query Cassandra, but alter them to be idempotent and to connect to an existent node, instead of spinning up/down an instance in test setup/teardown. (1) requires that you have some way of pointing the build at a local copy of a Cassandra tree (as I remember it, there were some that didn't care for this). (2) means that you'd need the corresponding driver installed (or an embedded copy as the case may be) in order to run those tests. (3) seems to be most consistent with how other people do it for code that connects to some service. -- Eric Evans Acunu | http://www.acunu.com | @acunu
