TestDriver

[Brock Noland <br...@cloudera.com>]

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 - http://incubator.apache.org/mrunit/

Re: TestDriver

[Brock Noland <br...@cloudera.com>]

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 <da...@paraliatech.com> 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 <br...@cloudera.com> 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 -
>> http://incubator.apache.org/mrunit/
>>



-- 
Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/

Re: TestDriver

[Dave Beech <da...@paraliatech.com>]

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 <br...@cloudera.com> 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 -
> http://incubator.apache.org/mrunit/
>