For what it is worth, my preference would be to have unit tests that would form a regression testing package in the tree with the client sources. Ideally the build package (whether dedicated or mixed in with the server) would have specific tasks to build, test and install/deploy devoted to the individual client in question.
I suggest that the client should not need to rely on anything but JAR files and local configuration to do the build and test. If they needed to be coordinated with a server build then perhaps some utility tasks to copy current jars for the server build site to the client build site would be useful. Config files local to the client build/test would point to test C* configs as appropriate. I think that makes me favor option #3. On Sep 2, 2011, at 4:52 PM, Eric Evans wrote: > 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
