[
https://issues.apache.org/jira/browse/MRUNIT-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Beech updated MRUNIT-91:
-----------------------------
Attachment: MRUNIT-91-1.patch
Hi Jim - updated patch here. I pasted in your test into TestMapDriver and,
after a little head-scratching, realised that it was passing because only one
key value pair is supported at a time, so there was no duplicate input after
all.
The same test run in a MapReduceDriver did fail but gave no error message. So
I've added an extra check at the end of "validate" to look for Pairs in the
actual output set that have no t been accounted for. This will hopefully solve
the issue.
> runTest() should optionally ignore output order
> -----------------------------------------------
>
> Key: MRUNIT-91
> URL: https://issues.apache.org/jira/browse/MRUNIT-91
> Project: MRUnit
> Issue Type: Improvement
> Affects Versions: 0.8.1
> Reporter: William McNeill
> Priority: Minor
> Labels: order
> Fix For: 1.0.0
>
> Attachments: MRUNIT-91-1.patch, MRUNIT-91.patch
>
>
> Currently MapDriver.runTest() assumes that the order of pairs emitted by the
> mapper matches the order of the MapDriver.addOutput() calls. However, there
> are valid mappers that for a given input pair produce output pairs whose
> order is unspecified for testing purposes. (For example, if the mapper being
> tested uses a set object for deduplication before emission.) runTest() cannot
> be used to test these kinds of mappers.
> A workaround is to not use runTest() but instead put the output of run() into
> a Set and assert that the contents of the set are correct, bypassing MRUnit's
> validation code.
> A possible improvement would be to add a boolean orderMatters parameter to
> MapDriver.runTest(), invoking an order-insensitive version of
> TestDriver.validate() when orderMatters is false and the existing version
> otherwise.
> For clarity's sake only mappers are discussed in this feature request, but
> the same applies to reducers as well.
--
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
