Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # dev >> Better testing for client code...


Copy link to this message
-
Re: Better testing for client code...
I am all for using mockito. I have found it very handy in writing good
unit tests. Our codebase needs little changes to be able to unit test
our codebase.

Writing a "real" unit test for the java client would be a good use
case to see what all changes need to happen on the client.

thanks
mahadev

On Mon, Oct 31, 2011 at 1:20 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> I've been thinking that we need better testing for the client code. In
> particular it's currently difficult to simulate all the different
> types of failures a client might see. I'm wondering how we might do
> this - two ideas come to mind; 1) aspectj and 2) mocks (mockito).
> Anyone have other suggestions?
>
> I've used 1 before on an ad-hoc basis to find issues in the server
> quorum code (aspects which would randomly cause a connect, bind,
> write, read, etc.... to fail). 2 seems better from a deterministic
> basis (ie repeatable tests that are easier to verify pass/fail). The
> only issue I see with 2 (other than refactoring some of the client
> code) is the need to mock networking level code. Perhaps both
> approaches could be applied together or separately.
>
> Thoughts?
>
> Patrick
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB