The standard reasoning for unit tests is specificity of errors. Well written tests suites tell you where you screwed up exactly just by the success and failure pattern, often cutting down the need for a debugger.
System tests standard rational is validating these units are wired up correctly. Hence where the doubling up of having system tests and unit tests occasionally overlap code pathways is considered worth it. In my experience, unless everyone is on board with crafting isolated unit tests well however the promised Nirvana of rapid feedback, specific errors and proper test coverage never happens. On May 21, 2014 4:07 AM, "Sylvain Lebresne" <sylv...@datastax.com> wrote: > Just to be clear, I'm not strongly opposed to having CQL tests in the unit > tests suite per-se (I happen to find dtests easier to work with, probably > because I don't use debuggers, but I'm good with saying that this just mean > I'm crazy and shouldn't be taken into account). Having tests that are > intrinsically > the same kind of tests in two places bugs me a bit more however. We > currently > have all of our CQL tests in dtests ( > https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py) > and there is quite a bunch of them. Here we're talking about starting to > slowly > add the same kind of tests in the unit test suite. So do we start adding > every > new CQL test from now on in the unit tests? And what about the existing > tests? > > -- > Sylvain > > > > On Wed, May 21, 2014 at 4:51 AM, Brandon Williams <dri...@gmail.com> > wrote: > > > On Tue, May 20, 2014 at 6:42 PM, Jonathan Ellis <jbel...@gmail.com> > wrote: > > > > > 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. > > > > > > This. > > >
