Given a unit and a system test that cover the same code, the unit test is 10x more useful when something breaks. It's difficult to run dtests locally at all, let alone attach your debugger to the right instance at the right time to troubleshoot deeper.
So my preferred approach is, unit test when possible without writing a lot of scaffolding and mock superstructure. Mocking is your code telling you to write a system test. On May 20, 2014 6:11 PM, "Tyler Hobbs" <ty...@datastax.com> wrote: > Sylvain and I have been having a discussion about testing CQL in unit tests > vs dtests. I'd like to hear if there are any other opinions on the topic. > > We currently only test CQL queries through dtests. I'd like to start > adding unit tests that exercise CQL where it makes sense. To me, dtests > make sense when: > - Multiple nodes are needed > - Nodes need to be shutdown, replaced, etc > - We specifically want end-to-end testing > > When we don't need those, I'd like to use unit tests because: > - They're typically quicker to run (especially with an IDE) > - Unit tests tend to be run earlier and more often than dtests > - There are fewer moving parts to break (no ccm or dtest machinery) > - It's easier to use a debugger > > But Sylvain makes some good points about keeping all CQL tests in the > dtests: > - All of the related tests are in one place > - Python tends to be more concise and easier to read and write (especially > for tests) > - dtests are always fully end-to-end > > I agree that Python can be nicer to work with, but Java hasn't been too bad > in my experience[1]. And we do need end-to-end tests, just not on every > test case. > > Does anybody else have an opinion on starting to use unit tests for some > CQL testing vs keeping everything in dtests? > > [1] > > https://github.com/thobbs/cassandra/blob/CASSANDRA-6875-2.0/test/unit/org/apache/cassandra/cql3/MultiColumnRelationTest.java > -- > Tyler Hobbs > DataStax <http://datastax.com/> >
