[
https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401224#comment-13401224
]
Bertrand Dechoux commented on MRUNIT-119:
-----------------------------------------
> - The patch is in git format - could you provide one against the current
> trunk of the svn repo? I'm not sure our git mirror is completely up-to-date.
Sure. I was more familiar with github way of working so I used it for a first
attempt. But I will submit a diff again against svn trunk.
> - Please use 2 spaces for indenting rather than 4 spaces or a tab (2 spaces
> is the Hadoop standard)
I didn't know it was Hadoop standard. Is there a way to to load this particular
configuration? It would be helpful to have the formatter settings inside the
source code repository. I know it is possible for Eclipse, must be the same for
other IDEs. I am not saying that IDEs specific configuration should be added to
the repository if there is a choice. With regard to global project
configuration, the master file should still be the pom.xml for maven because
IDE specific configuration can be derived from it. But for formatting, there is
no IDE agnostic solution as far as I know.
> - Could you please add unit tests to cover the use of mapreduce api as well
> as mapred, and enum counters as well as the string pairs. I realise the code
> is the same for each right now, but because of the duplication we may
> introduce bugs if we change one api and forget to update the other.
Sure. Here are all the variations that should be tested :
(Map,Reduce,MapReduce),(Old API,New API), (Enum counter, String counter),
(Failure, Success), (At least one expected counter, no expected counter). I
will see how I can add them to the current test suite.
> Also, the use case of the new feature is different to how I originally
> interpreted your message on the mailing list, so I'd like to double check
> that I understand your requirement correctly. Is the following right? You
> have a counter, for example an error counter, that you want to ensure does
> not get set. However, the counter name can be dynamic so you cannot know
> up-front what to assert in the unit test.
First, I might not have been using the right vocabulary. I usually tend to
think of (groupName,counterName) as the (full) counter name. At the moment,
this full name is 'dynamic' (it may only be the class name but it is still
dynamic during refactoring). Second, I only use counters for warnings and
errors ie something unexpected happened. I want to be able to assert a good
case ie no counters were incremented. But also the logic of counter usage ie
for a particular case counter1 was incremented, so no other counters should be
incremented, not counter2, not counter3 ...
With regard to the logic of the strict checking, the debate is almost the same
as EasyMock versus Mockito. In most cases, specifying everything is a bad idea
because it will make your tests brittle. But there are always cases where you
want to do that and that's why even in Mockito you have methods such as
verifyZeroInteractions/verifyNoMoreInteractions. Of course, it assumes the user
should be careful because if they use it everywhere they will be hurt.
At the moment, regex expressions would not help me. Even if the counter name is
dynamic eg "error "+variable, I know the 'static' results during the test
because I am in control of the execution environment. So I would check "error
42" if variable was 42 for example.
> Counter tests should support assertions that counters are not present
> ---------------------------------------------------------------------
>
> Key: MRUNIT-119
> URL: https://issues.apache.org/jira/browse/MRUNIT-119
> Project: MRUnit
> Issue Type: Improvement
> Affects Versions: 1.0.0
> Reporter: Dave Beech
> Priority: Minor
> Attachments: mrunit-119-proposal.diff
>
>
> From Bertrand Dechoux via user mailing list.
> Should we add a feature to the counter checking feature so that users can
> assert that something will *not* be present, for example an error or
> exception counter, and have the test fail if it is set?
--
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
