mrunit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brock Noland <>
Subject Re: TestDriver
Date Thu, 22 Nov 2012 14:52:29 GMT
Yeah, we might have to have lazy creates of these things (including
the mock context) and then document that if you are going to set a
config object, it should be the first thing you do. Perhaps even
deprecate that method and create another constructor?

The scenario I am seeing is this. The Mock Context is going to need
the conf object to implement MRUNIT-161 but it's also possible to get
a hold of the context via the getContext() method in which case we
obviously have to create it before the run() method but after which
point the setConf method could still be called.

On Thu, Nov 22, 2012 at 8:36 AM, Dave Beech <> wrote:
> Probably. There are other issues like this, for
> example setKeyGroupingComparator and setKeyOrderComparator on
> MapReduceDriverBase create an instance of the comparator straight away,
> using whatever conf is currently available.
> If the user decides to provide a different config later which contains
> settings that would have been used when creating the comparators, well ....
> unlucky. I mentioned this on one of the issues in JIRA but can't remember
> right now which one it was.
> If possible I think we should defer creation of these objects until right
> before the test starts running.
> Dave
> On 22 November 2012 14:24, Brock Noland <> wrote:
>> In TestDriver:
>>     configuration = new Configuration();
>>     serialization = new Serialization(configuration);
>> in the constructor but then we allow people to set the configuration
>> object without re-creating the Serialization object. Is this
>> problematic?  I am looking at MRUNIT-161 which will require the
>> configuration object as well, but down in the Mock*Context classes.
>> Brock
>> --
>> Apache MRUnit - Unit testing MapReduce -

Apache MRUnit - Unit testing MapReduce -

View raw message