[
https://issues.apache.org/jira/browse/MRUNIT-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224893#comment-13224893
]
Jim Donofrio commented on MRUNIT-69:
------------------------------------
I would think we should still be compatible with JUnit due to the good support
from IDE's
I agree that @MapTest(mapper = IdentityMapper.class) should not go on the
method but the class. I am not sure we want to extend
MapperTest<CoolMapper.class>. JUnit used to do this but went a way from that to
do assertion based testing.
I think the withInput(key, value).withOutput(key, value) is a good idea but it
would be ideal to not have to call run() everytime. There also needs to be a
withJobConf(conf) or a withJobConfParam("key", value)
> longterm plan for MRUNIT development?
> -------------------------------------
>
> Key: MRUNIT-69
> URL: https://issues.apache.org/jira/browse/MRUNIT-69
> Project: MRUnit
> Issue Type: Brainstorming
> Reporter: Jim Donofrio
> Priority: Minor
>
> So I am curious what the plan is for the longterm future of MRUNIT?
> I think currently MRUNIT is useful for just unit testing a single mapper or
> reducer but currently there is a void for testing more complicated features
> such as MultipleInputs, MultipleOutputs, a driver class, counters, among
> other things. I wonder if instead of adding support to the current MRUNIT
> framework for these extra features it would more useful to add in hooks to
> the existing LocalJobRunner and MiniMRCluster classes to provide methods to
> more easily verify file output from text files, sequence files, etc. This
> would allow MRUNIT to test driver classes, MultipleInputs, MultipleOutputs,
> etc. MRUNIT would also then test against the real hadoop code instead of an
> implementation that mimics hadoop which can miss some bugs such as the
> ReduceDriver that did not reuse the same object until 0.8.0. MRUNIT would
> also keep up with new map reduce features instead of us having to implement
> fake versions of them
> I understand that performance would be an issue due to the file I/O but I
> wonder how fast the LocalJobRunner would be if we wrote a new class that
> extending FileSystem to allow users to write out fake files to memory and
> make the LocalJobRunner read from them
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
