This all looks reasonable to me. I wonder if most mocking tools don't
support programmatic definition of return values because it makes the
declaration of expectations less explicit.
On Fri, Oct 28, 2011 at 11:19 AM, John W Vines <[EMAIL PROTECTED]> wrote:
> I will start off by saying that myself, as well as most of the committers, are no familiar with EasyMock, PowerMock, or really any Mocking tools. But I've done some reading to determine what the scope of mocking can get us. So pardon me if I bore you because I'm just going to lay out what I know in hopes of A. making sure my understanding is correct and B. to see if what I think we should use it for is within the scope of Mocking as well as feasible.
> 1. With exception for PowerMock, mocking tools are nothing more than tools which give the ability to define a pre-set set of responses to an interface. That is, if we wanted to implement a low level iterator to replace the Reader we use to read items off disk/out of the in memory map, we could, but we could only give it a set of responses to give when queried. We could not (through just the mocking tools) set it up to give programmatic responses, such as returning the result of another method, unless we 'pre-load' the method result. That is, we couldn't have one mock method which put an item in a map and another mock method pull it out again, unless we define the pull method to return that specific value for the Xth call to the pull method to which that correlated.
> 2. PowerMock lets us essentially do the same as things like EasyMock, except we're not bound to interfaces. This way we can use a defined class and only overwrite the methods we want with predefined results.
> 3. What I want to see us doing, at a very high level, is to have the ability to mock an entire TServer to the extent where we will use something to replace Zookeeper (We should probably turn our ZK work with an interface) with a MockZookeeper (not generated through a Mock util) which is nothing more than a Map. Same thing with the FileReader, except a SortedMap, the loggers, and the master. This way we could fully implement a whole TServer without worry about HDFS and Zookeeper. To a similar extent I would like to see this done for all core components, but mocking the various connectors we use to get done what we need to. I see a few sets of Mock class we will have to create. But with less chance of divergence in behavior then we currently experience with our MockAccumulo setup.
> 4. My principal concern about 3 above is divergence with the code (less so than our current setup but with emulating thrift interfaces we could get problems). But also the feasibility of mocking thrift connections. But if all this works out, I think we'll be able to optimize our code coverage better than our current setup without the requirement to do a full Accumulo setup for junit tests.
> ----- Original Message -----
> | From: "Jesse Yates" <[EMAIL PROTECTED]>
> | To: [EMAIL PROTECTED]
> | Sent: Thursday, October 27, 2011 2:21:33 PM
> | Subject: Re: Mocking framework
> | On Thu, Oct 27, 2011 at 10:55 AM, Drew Farris <[EMAIL PROTECTED]> wrote:
> | > I agree in principle without having reviewed the tests accompanying
> | > ACCUMULO-53.
> | >
> | > I've used EasyMock in the past and have been very happy with the
> | > ability to programatically mock implementations of interfaces,
> | > define
> | > test input and assert a proper sequence of calls, and output. In
> | > general I think mock object testing is a useful tool, especially in
> | > cases where the existing interface implementations have heavyweight
> | > external dependencies, such as for mocking JDBC result sets or
> | > portions of the Hadoop framework. I've used mock objects to write
> | > unit
> | > tests for mappers and reducers by mocking out the hadoop context,
> | > counters, etc. Arguably this would be have been better achieved with
> | > MRUnit, which wasn't on my radar at the time.