mrunit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bertrand Dechoux (JIRA)" <>
Subject [jira] [Commented] (MRUNIT-119) Counter tests should support assertions that counters are not present
Date Tue, 26 Jun 2012 07:52:42 GMT


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
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:
>             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:!default.jspa
For more information on JIRA, see:


View raw message