I also like mockito. It has some limitations but generally can be very useful. However, I'm also very much a fan of fixing our code base to be more testable against real servers. I actually like the fact that we use a lot of "integration" testing in our automated build. You do catch things that you would miss in mockito unless you were very good at thinking through all possible orderings of behavior.
My internal ZK java client testing goes almost entirely against mockito and in retrospect I think I would've been possibly better off using mostly a real server started by the unit tests. Not that I missed a lot of bugs using mockito, but what I gained in speed of tests I lost in readability of the test cases for people that aren't fluent in mocking. Aspects are still a deep mystery to me. I know they can be terribly useful but wow are they hard to read. I can probably throw together a few quick mockito sample tests to get the ball rolling on this. After I look at some of the patch backlog. C -----Original Message----- From: Mahadev Konar [mailto:[email protected]] Sent: Tuesday, November 01, 2011 12:52 AM To: [email protected] Subject: 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 >
