mrunit-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Eade <>
Subject Comparing classes vs. instanceof in TestDriver
Date Thu, 11 Jul 2013 04:40:40 GMT

I don't want my test case to rely on the same processing as the job it is
testing.  To this end, rather than using the output class of the job I want
to extend the output class to include direct access to internals for
testing purposes.

I would like to have:

public class MyWritable implemnts Writable {
    protected int someValue = 0;

    public doSomething(int increment) { // invoked in reducer
        someValue += increment; // contrived example
    // and a bunch of other stuff

public class MyWritableTestExt extends MyWritable {
    public setSomeValue(int someValue) { // invoked in test case
        this.someValue = someValue;

My reducer can emit MyWritable after invoking doSomething() as necessary as
part of its processing.  In my test case I can expect a MyWritableTestExt
that I configure using setSomeValue().

Sounds good, but my test fails with:
Mismatch in value class: expected: MyWritableTestExt actual: MyWritable

Would it make sense for
org.apache.hadoop.mrunit.TestDriver.checkTypesAndLogError() to use:
    if (expectedValueClass instanceof actualValueClass)
rahter than
    if (actualValueClass != expectedValueClass)
to check the types?

The same might apply to keys as well as values.

Is this a sensible suggestion or am I missing something?  It seems that
without this either my test case has to replicate the reducer code (not
ideal) or I have to pollute the MyWritable with test code.



View raw message