Why no mock objects in Hadoop? [was Unit test Examples for Mapper and Reducer?]

[kate rhodes <ma...@gmail.com>]

On 9/21/07, Nigel Daley <nd...@yahoo-inc.com> wrote:
> All the junit tests in hadoop are system type tests (as you've
> noted).  But, since Mapper and Reducer method parameters are all
> interfaces, it should be easy to use something like EasyMock or jMock
> to mock the input parameters and test your classes.

You are correct... in part. There are two problems that I discovered with this.
1) JobConf does not implement an interface it extends Configuration
and the only thing Configuration implements is Iterable.
2) and this is the scary one... There are NO mock object libraries OR
objects in Hadoop. OMFGWTFBBQ. Seriously guys. This means there's
*probably* not a single UNIT test in Hadoop, just lots of integration
and system tests. Not to diss the integration tests you guys have
written but they're NOT unit tests and that fact means that you're
just hurting yourselves when it comes time to debug because a bug in
one class has the potential to show up as a failure in any of the
other classes that use it in their tests, which can mislead you into
thinking that you've got a bug in a class that's perfectly fine.

Now, I've got no problems using EasyMock and / or jMock for testing my
personal apps I do it all the time, but it means that I can't add any
to Hadoop without convincing someone to add in one of those two jars
(actually in jMock's case it looks like a whole pile-o-jars).

If someone will add EasyMock or jMock to Hadoop I'd be willing to help
refactor some of the existing tests that were intended to be unit
tests. Or, if there's a potential licencing issue with distributing it
with Hadoop at least declare one of them to be a defacto part of
Hadoop (like the missing ant.jar) so that people can start writing
tests that use them.

Speaking of which WHY is the ant.jar not included with Hadoop? It
depends on it, and there's obviously not a licensing issue, but you
can't do half the things in it without copying it into the lib dir.

-- 
- kate = masukomi
http://weblog.masukomi.org/

Re: Why no mock objects in Hadoop?

[kate rhodes <ma...@gmail.com>]

On 9/24/07, Dmitry <dm...@hotmail.com> wrote:
> Hey,
> What actually better to use for Hadoop  - EasyMock or JMock ? Any comparison
> table  between them?

I prefer EasyMock's API but in the case of Hadoop I'd recommend jMock
just because its "THE" mock object suite for Java and considering how
hard it is to get anyone to use mock objects in the first place I vote
for the tool that's going to require fewer people to learn something
new. Also I *think* jMock handles mocking of classes that don't
implement an interface better. Not that you should be doing that
anyway but if it comes down to no mock or mock a concrete class i'll
take the latter.


-- 
- kate = masukomi
http://weblog.masukomi.org/

Re: Why no mock objects in Hadoop?

[Dmitry <dm...@hotmail.com>]

Hey,
What actually better to use for Hadoop  - EasyMock or JMock ? Any comparison 
table  between them?

Thanks
DT
----- Original Message ----- 
From: "Nigel Daley" <nd...@yahoo-inc.com>
To: <ha...@lucene.apache.org>
Sent: Monday, September 24, 2007 12:56 PM
Subject: Re: Why no mock objects in Hadoop?


>
> On Sep 22, 2007, at 2:59 PM, kate rhodes wrote:
>
>> On 9/21/07, Nigel Daley <nd...@yahoo-inc.com> wrote:
>>> All the junit tests in hadoop are system type tests (as you've
>>> noted).  But, since Mapper and Reducer method parameters are all
>>> interfaces, it should be easy to use something like EasyMock or jMock
>>> to mock the input parameters and test your classes.
>>
>> You are correct... in part. There are two problems that I  discovered 
>> with this.
>> 1) JobConf does not implement an interface it extends Configuration
>> and the only thing Configuration implements is Iterable.
>> 2) and this is the scary one... There are NO mock object libraries OR
>> objects in Hadoop. OMFGWTFBBQ. Seriously guys. This means there's
>> *probably* not a single UNIT test in Hadoop, just lots of integration
>> and system tests. Not to diss the integration tests you guys have
>> written but they're NOT unit tests and that fact means that you're
>> just hurting yourselves when it comes time to debug because a bug in
>> one class has the potential to show up as a failure in any of the
>> other classes that use it in their tests, which can mislead you into
>> thinking that you've got a bug in a class that's perfectly fine.
>
> Welcome to Open Source :-)  Definitions on what unit tests are/aren't 
> w.r.t. to OOP have only recently started to converge around those 
> popularized by Martin Fowler, Kent Beck, et al. ('converge' is likely  too 
> strong a word).  It's possible that many developers aren't test  driven, 
> don't keep up on the test philosophy du jour, and/or don't  agree with 
> these definitions.  Most days I'm just grateful that our  agreed upon code 
> review guidelines include checks for tests:
> http://wiki.apache.org/lucene-hadoop/CodeReviewChecklist
>
>> Now, I've got no problems using EasyMock and / or jMock for testing my
>> personal apps I do it all the time, but it means that I can't add any
>> to Hadoop without convincing someone to add in one of those two jars
>> (actually in jMock's case it looks like a whole pile-o-jars).
>
> You can always submit it as part of a patch if the library is license 
> compatible:
> http://people.apache.org/~cliffs/3party.html
>
>
> Nige
> 

Re: Why no mock objects in Hadoop?

[kate rhodes <ma...@gmail.com>]

> Welcome to Open Source :-)  Definitions on what unit tests are/aren't
> w.r.t. to OOP have only recently started to converge around those
> popularized by Martin Fowler, Kent Beck, et al. ('converge' is likely
> too strong a word).  It's possible that many developers aren't test
> driven, don't keep up on the test philosophy du jour, and/or don't
> agree with these definitions.

For me it's not so much that it's the philosophy do jour, and I'm not
really that picky about what people call it but I do believe that it's
provably better in almost all cases to have fully isolated unit tests
(regardless of what name people want to apply to them).  It doesn't
matter much to me what tools or methods are used to get there so long
as they don't hamper my ability to write tests and helps my ability to
discover / prevent bugs.


>Most days I'm just grateful that our
> agreed upon code review guidelines include checks for tests:
> http://wiki.apache.org/lucene-hadoop/CodeReviewChecklist

Yeah, no complaints there. :)


>
> You can always submit it as part of a patch if the library is license
> compatible:
> http://people.apache.org/~cliffs/3party.html

I'll look into that.

-- 
- kate = masukomi
http://weblog.masukomi.org/

Re: Why no mock objects in Hadoop?

[Nigel Daley <nd...@yahoo-inc.com>]

On Sep 22, 2007, at 2:59 PM, kate rhodes wrote:

> On 9/21/07, Nigel Daley <nd...@yahoo-inc.com> wrote:
>> All the junit tests in hadoop are system type tests (as you've
>> noted).  But, since Mapper and Reducer method parameters are all
>> interfaces, it should be easy to use something like EasyMock or jMock
>> to mock the input parameters and test your classes.
>
> You are correct... in part. There are two problems that I  
> discovered with this.
> 1) JobConf does not implement an interface it extends Configuration
> and the only thing Configuration implements is Iterable.
> 2) and this is the scary one... There are NO mock object libraries OR
> objects in Hadoop. OMFGWTFBBQ. Seriously guys. This means there's
> *probably* not a single UNIT test in Hadoop, just lots of integration
> and system tests. Not to diss the integration tests you guys have
> written but they're NOT unit tests and that fact means that you're
> just hurting yourselves when it comes time to debug because a bug in
> one class has the potential to show up as a failure in any of the
> other classes that use it in their tests, which can mislead you into
> thinking that you've got a bug in a class that's perfectly fine.

Welcome to Open Source :-)  Definitions on what unit tests are/aren't  
w.r.t. to OOP have only recently started to converge around those  
popularized by Martin Fowler, Kent Beck, et al. ('converge' is likely  
too strong a word).  It's possible that many developers aren't test  
driven, don't keep up on the test philosophy du jour, and/or don't  
agree with these definitions.  Most days I'm just grateful that our  
agreed upon code review guidelines include checks for tests:
http://wiki.apache.org/lucene-hadoop/CodeReviewChecklist

> Now, I've got no problems using EasyMock and / or jMock for testing my
> personal apps I do it all the time, but it means that I can't add any
> to Hadoop without convincing someone to add in one of those two jars
> (actually in jMock's case it looks like a whole pile-o-jars).

You can always submit it as part of a patch if the library is license  
compatible:
http://people.apache.org/~cliffs/3party.html


Nige