retty reasonable.
> >
> > Ben
> > ____
> > From: Shahab Yunus [shahab.yu...@gmail.com]
> > Sent: Wednesday, June 19, 2013 8:46 AM
> > To: user@cassandra.apache.org
> > Subject: Re: Unit Testing Cassandra
> >
> > Thanks S
ther in the embedded database.
> >
> > Setup/tear down time is pretty reasonable.
> >
> > Ben
> >
> > From: Shahab Yunus [shahab.yu...@gmail.com]
> > Sent: Wednesday, June 19, 2013 8:46 AM
> > To: user@cassandra.apache.org
> > Subject: Re: Unit Test
.
>
> Setup/tear down time is pretty reasonable.
>
> Ben
>
> From: Shahab Yunus [shahab.yu...@gmail.com]
> Sent: Wednesday, June 19, 2013 8:46 AM
> To: user@cassandra.apache.org
> Subject: Re: Unit Testing Cassandra
>
> Thanks Stephen f
ur data so different tests don't collide with each other
in the embedded database.
Setup/tear down time is pretty reasonable.
Ben
From: Shahab Yunus [shahab.yu...@gmail.com]
Sent: Wednesday, June 19, 2013 8:46 AM
To: user@cassandra.apache.org
Subject: R
"user@cassandra.apache.org<mailto:user@cassandra.apache.org>"
mailto:user@cassandra.apache.org>>
Date: Wednesday, June 19, 2013 6:46 AM
To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>"
mailto:user@cassandra.apache.org>>
Subject: Re: Unit Testing Cassandra
Thanks Stephen for you reply and explanation. My bad that I mixed those up
and wasn't clear enough. Yes, I have different 2 requests/questions.
1) One is for the unit testing.
2) Second (in which I am more interested in) is for performance
(stress/load) testing. Let us keep integration aside for
Unit testing means testing in isolation the smallest part.
Unit tests should not take more than a few milliseconds to set up and
verify their assertions.
As such, if your code is not factored well for testing, you would typically
use mocking (either by hand, or with mocking libraries) to mock out
