You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@accumulo.apache.org by David Medinets <da...@gmail.com> on 2013/09/24 14:58:47 UTC

Has anyone used mrunit to test Mutations produced from Mappers or Reducers?

http://stackoverflow.com/questions/18541143/how-to-test-a-reducer-containing-a-mutation-
there is a question on Stack Overflow about this. And I would not mind
knowing the answer also.

Re: Has anyone used mrunit to test Mutations produced from Mappers or Reducers?

Posted by David Medinets <da...@gmail.com>.
I am using mrunit like this:

Mutation expected = new Mutation();
expected.put(...);
expected.put(...);

MapDriver mapDriver = new MapDriver<....>();
mapDriver.withMapper(...);
mapDriver.withInput(...);
mapDriver.withConfiguration(...);
mapDriver.withOutput(null, expected);
mapDriver.runTest();

As such, mrunit is unable to correctly check the expected Mutation.
However, I seem to have a workaround:

Mutation expected = new TestableMutation();

The rest of the code is unchanged. My TestableMutation class is quite
simple:

public class TestableMutation extends Mutation {
  TestableMutation(Text row) {
    super(row);
  }
  @Override
  public boolean equals(Mutation other) {
    return true;
  }
}

I'll leave it as an exercise to the reader to create a better equals method.



On Tue, Sep 24, 2013 at 12:31 PM, Eric Newton <er...@gmail.com> wrote:

> Created https://issues.apache.org/jira/browse/ACCUMULO-1734 in response.
>
> -Eric
>
>
>
> On Tue, Sep 24, 2013 at 12:19 PM, Tim Reardon <te...@gmail.com> wrote:
>
>> The problem is that Mutation.equals() calls a private serialize() method
>> that modifies the data about to be checked. I have successfully worked
>> around this in the past by wrapping the Mutation in a new Mutation, which
>> calls serialize under the hood:
>>
>>  assertEquals(expectedMutation, new Mutation(actualMutation));
>>
>> This applies to 1.4.x, I don't know if Mutation.equals() has changed
>> since then.
>>
>> Tim
>>
>> On Tue, Sep 24, 2013 at 8:58 AM, David Medinets <david.medinets@gmail.com
>> > wrote:
>>
>>>
>>> http://stackoverflow.com/questions/18541143/how-to-test-a-reducer-containing-a-mutation- there is a question on Stack Overflow about this. And I would not mind
>>> knowing the answer also.
>>>
>>
>>
>

Re: Has anyone used mrunit to test Mutations produced from Mappers or Reducers?

Posted by Eric Newton <er...@gmail.com>.
Created https://issues.apache.org/jira/browse/ACCUMULO-1734 in response.

-Eric



On Tue, Sep 24, 2013 at 12:19 PM, Tim Reardon <te...@gmail.com> wrote:

> The problem is that Mutation.equals() calls a private serialize() method
> that modifies the data about to be checked. I have successfully worked
> around this in the past by wrapping the Mutation in a new Mutation, which
> calls serialize under the hood:
>
>  assertEquals(expectedMutation, new Mutation(actualMutation));
>
> This applies to 1.4.x, I don't know if Mutation.equals() has changed since
> then.
>
> Tim
>
> On Tue, Sep 24, 2013 at 8:58 AM, David Medinets <da...@gmail.com>wrote:
>
>>
>> http://stackoverflow.com/questions/18541143/how-to-test-a-reducer-containing-a-mutation- there is a question on Stack Overflow about this. And I would not mind
>> knowing the answer also.
>>
>
>

Re: Has anyone used mrunit to test Mutations produced from Mappers or Reducers?

Posted by Tim Reardon <te...@gmail.com>.
The problem is that Mutation.equals() calls a private serialize() method
that modifies the data about to be checked. I have successfully worked
around this in the past by wrapping the Mutation in a new Mutation, which
calls serialize under the hood:

 assertEquals(expectedMutation, new Mutation(actualMutation));

This applies to 1.4.x, I don't know if Mutation.equals() has changed since
then.

Tim

On Tue, Sep 24, 2013 at 8:58 AM, David Medinets <da...@gmail.com>wrote:

>
> http://stackoverflow.com/questions/18541143/how-to-test-a-reducer-containing-a-mutation- there is a question on Stack Overflow about this. And I would not mind
> knowing the answer also.
>