You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mrunit.apache.org by "Dave Beech (JIRA)" <ji...@apache.org> on 2012/06/18 09:59:44 UTC
[jira] [Created] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Dave Beech created MRUNIT-119:
---------------------------------
Summary: 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
>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
[jira] [Commented] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Jarek Jarcec Cecho (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13424611#comment-13424611 ]
Jarek Jarcec Cecho commented on MRUNIT-119:
-------------------------------------------
The idea behind string counter checking seems fine to me. I've also checked the patch and I do not have any comments or objections. Jim, please feel free to commit it.
I'll work on MRUNIT-125 after this one will get committed.
Jarcec
> 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
> Assignee: Bertrand Dechoux
> Priority: Minor
> Attachments: mrunit-119-proposal.diff, mrunit-119-proposal.diff, mrunit-119.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
[jira] [Commented] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Jarek Jarcec Cecho (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13423903#comment-13423903 ]
Jarek Jarcec Cecho commented on MRUNIT-119:
-------------------------------------------
I'll review it and put my feedback over the weekend.
Jarcec
> 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
> Assignee: Bertrand Dechoux
> Priority: Minor
> Attachments: mrunit-119-proposal.diff, mrunit-119-proposal.diff, mrunit-119.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
[jira] [Commented] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Bertrand Dechoux (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Jim Donofrio (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13423839#comment-13423839 ]
Jim Donofrio commented on MRUNIT-119:
-------------------------------------
Bertrand,
I create a ticket MRUNIT-125 for reducing the duplicate code
> 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
> Assignee: Bertrand Dechoux
> Priority: Minor
> Attachments: mrunit-119-proposal.diff, mrunit-119-proposal.diff, mrunit-119.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
[jira] [Resolved] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Jim Donofrio (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Donofrio resolved MRUNIT-119.
---------------------------------
Resolution: Fixed
Fix Version/s: 1.0.0
committed in 1367010
> 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
> Assignee: Bertrand Dechoux
> Priority: Minor
> Fix For: 1.0.0
>
> Attachments: mrunit-119-proposal.diff, mrunit-119-proposal.diff, mrunit-119.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
[jira] [Commented] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Dave Beech (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13400329#comment-13400329 ]
Dave Beech commented on MRUNIT-119:
-----------------------------------
Hi Bertrand
Looks good so far. I haven't had time to check it properly yet unfortunately, but here are a couple of things I noticed:
- 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.
- Please use 2 spaces for indenting rather than 4 spaces or a tab (2 spaces is the Hadoop standard)
- 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.
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.
I can see how the "strict mode" would solve this, as you're basically saying "I don't know what the error will look like, so fail the test if you see anything other than those counters I was expecting". However, if you have dynamic "non-error" counters too, or counters you simply don't care about either way, the strict mode wouldn't be suitable. I am concerned that the strict mode might make the unit tests unnecessarily brittle, as you will no doubt add / remove / rename valid counters during development and refactoring, and this will make all your strict counter tests fail. This might be OK, but I can imagine it being inconvenient for some.
How I originally imagined the feature when I read the message was to add something like driver.withNoCounter("Error", "Some error") or even a regex version driver.withNoCounter("Error", ".+Exception") - so you can selectively assert that certain counters should not be present, but ignore everything else.
Jarek - as you added the counter checking code originally, what do you think? Does anyone else have any thoughts on this?
> 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
[jira] [Commented] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Bertrand Dechoux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417145#comment-13417145 ]
Bertrand Dechoux commented on MRUNIT-119:
-----------------------------------------
I have started again with a fresh copy from the svn trunk and I do have a question.
There is a TestCounters class which should group everything related to counters but then every other Test*Driver has also test with counters.
Is that normal? Where should the additional test for this feature should be added?
> 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
[jira] [Commented] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Bertrand Dechoux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13423739#comment-13423739 ]
Bertrand Dechoux commented on MRUNIT-119:
-----------------------------------------
> I know that withCounter does this in TestDriver but withStrictCounterChecking in TestDriver does not need to return this because nothing uses its return value, it should probably also be protected since no user needs to call it.
Both methods have exactly the same use. And it is true that the return value is never used.
However, we really want in inheritance in order to share the documentation and to ensure that all classes extending TestDriver have those methods.
The only drawback with the current implementations is that we can not guarantee that all classes extending TestDriver will overwrite the default implementation in order to return a more specific return type : their own type.
The only clean way to do it would be to remove the default implementation in TestDriver (ie the method should be protected with a different name and no return value) and create an interface with the declaration of this method which should be 'implemented' by the abstract TestDriver. And so every classes extending TestDriver would need to define a correct implementation in order to compile.
But I guess this change would not be only related to those two methods. And that would be a refactoring which really should not be done by MRUNIT-19.
> validateExpectedAgainstActual should be private, only TestDriver uses it
Done. I will attach the patch again once we reach a conclusion on the first point.
> Good work, thanks for your contribution and sorry about out slow response, we look forward to more of our your contributions.
Nothing to be sorry about. I was only afraid that the notification saying that I had attached a new patch might have been lost.
> 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
> Assignee: Bertrand Dechoux
> Priority: Minor
> Attachments: mrunit-119-proposal.diff, 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
[jira] [Updated] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Bertrand Dechoux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bertrand Dechoux updated MRUNIT-119:
------------------------------------
Attachment: mrunit-119-proposal.diff
A proposal : add a strict mode for counter checking.
Basically, we want to have an error if a counter was observed but not expected. Of course, this mode is optional and should be activated only when needed.
> 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
[jira] [Updated] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Bertrand Dechoux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bertrand Dechoux updated MRUNIT-119:
------------------------------------
Attachment: mrunit-119.diff
Internal methods of validate(final CounterWrapper counterWrapper) are now private.
> 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
> Assignee: Bertrand Dechoux
> Priority: Minor
> Attachments: mrunit-119-proposal.diff, mrunit-119-proposal.diff, mrunit-119.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
[jira] [Assigned] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Jim Donofrio (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Donofrio reassigned MRUNIT-119:
-----------------------------------
Assignee: Bertrand Dechoux
> 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
> Assignee: Bertrand Dechoux
> Priority: Minor
> Attachments: mrunit-119-proposal.diff, 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
[jira] [Comment Edited] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Bertrand Dechoux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13423835#comment-13423835 ]
Bertrand Dechoux edited comment on MRUNIT-119 at 7/27/12 12:22 PM:
-------------------------------------------------------------------
Add a final diff : "Internal methods of validate(final CounterWrapper counterWrapper) are now private"
Good for inclusion into the trunk.
Your proposal is a good first step. It would remove duplicate code and uncertainty of method not being overwritten, while not impacting the end-user.
I can even take a first shot for the implementation of the ticket once created.
was (Author: bdechoux):
Internal methods of validate(final CounterWrapper counterWrapper) are now private.
> 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
> Assignee: Bertrand Dechoux
> Priority: Minor
> Attachments: mrunit-119-proposal.diff, mrunit-119-proposal.diff, mrunit-119.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
[jira] [Commented] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Jim Donofrio (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13423830#comment-13423830 ]
Jim Donofrio commented on MRUNIT-119:
-------------------------------------
This might be beyond the scope of this JIRA. Maybe it is best for you to just go with the current implementation of withStrictCounterChecking and we can open another JIRA to fix the general problem affecting this method and withCounter and others. We have a lot of duplicate code in order to have the fluent style methods
How about instead of another interface we add a unbound type parameter T to TestDriver and then all the fluent methods could go in TestDriver but return type T. The base classes, MapDriverBase etc, would just pass the T on so you would have:
public abstract class TestDriver<K1, V1, K2, V2, T>
public abstract class MapDriverBase<K1, V1, K2, V2, T> extends TestDriver<K1, V1, K2, V2, T>
public class MapDriver<K1, V1, K2, V2> extends MapDriverBase<K1, V1, K2, V2, MapDriver<K1, V1, K2, V2>>
> 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
> Assignee: Bertrand Dechoux
> Priority: Minor
> Attachments: mrunit-119-proposal.diff, 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
[jira] [Updated] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Bertrand Dechoux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bertrand Dechoux updated MRUNIT-119:
------------------------------------
Attachment: mrunit-119-proposal.diff
Add proposal based on svn trunk with more extensive tests.
> 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, 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
[jira] [Comment Edited] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Bertrand Dechoux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13423739#comment-13423739 ]
Bertrand Dechoux edited comment on MRUNIT-119 at 7/27/12 12:07 PM:
-------------------------------------------------------------------
> I know that withCounter does this in TestDriver but withStrictCounterChecking in TestDriver does not need to return this because nothing uses its return value, it should probably also be protected since no user needs to call it.
Both methods have exactly the same use. And it is true that the return value is never used.
However, we really want in inheritance in order to share the documentation and to ensure that all classes extending TestDriver have those methods.
The only drawback with the current implementations is that we can not guarantee that all classes extending TestDriver will overwrite the default implementation in order to return a more specific return type : their own type.
The only clean way to do it would be to remove the default implementation in TestDriver (ie the method should be protected with a different name and no return value) and create an interface with the declaration of this method which should be 'implemented' by the abstract TestDriver. And so every classes extending TestDriver would need to define a correct implementation in order to compile.
But I guess this change would not be only related to those two methods. And that would be a refactoring which really should not be done by MRUNIT-119.
> validateExpectedAgainstActual should be private, only TestDriver uses it
Done. I will attach the patch again once we reach a conclusion on the first point.
> Good work, thanks for your contribution and sorry about out slow response, we look forward to more of our your contributions.
Nothing to be sorry about. I was only afraid that the notification saying that I had attached a new patch might have been lost.
was (Author: bdechoux):
> I know that withCounter does this in TestDriver but withStrictCounterChecking in TestDriver does not need to return this because nothing uses its return value, it should probably also be protected since no user needs to call it.
Both methods have exactly the same use. And it is true that the return value is never used.
However, we really want in inheritance in order to share the documentation and to ensure that all classes extending TestDriver have those methods.
The only drawback with the current implementations is that we can not guarantee that all classes extending TestDriver will overwrite the default implementation in order to return a more specific return type : their own type.
The only clean way to do it would be to remove the default implementation in TestDriver (ie the method should be protected with a different name and no return value) and create an interface with the declaration of this method which should be 'implemented' by the abstract TestDriver. And so every classes extending TestDriver would need to define a correct implementation in order to compile.
But I guess this change would not be only related to those two methods. And that would be a refactoring which really should not be done by MRUNIT-19.
> validateExpectedAgainstActual should be private, only TestDriver uses it
Done. I will attach the patch again once we reach a conclusion on the first point.
> Good work, thanks for your contribution and sorry about out slow response, we look forward to more of our your contributions.
Nothing to be sorry about. I was only afraid that the notification saying that I had attached a new patch might have been lost.
> 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
> Assignee: Bertrand Dechoux
> Priority: Minor
> Attachments: mrunit-119-proposal.diff, 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
[jira] [Commented] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Dave Beech (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399395#comment-13399395 ]
Dave Beech commented on MRUNIT-119:
-----------------------------------
Bertrand - thanks! I'll try and take a look at your patch over the weekend.
> 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
[jira] [Commented] (MRUNIT-119) Counter tests should support
assertions that counters are not present
Posted by "Jim Donofrio (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MRUNIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13423044#comment-13423044 ]
Jim Donofrio commented on MRUNIT-119:
-------------------------------------
I know that withCounter does this in TestDriver but withStrictCounterChecking in TestDriver does not need to return this because nothing uses its return value, it should probably also be protected since no user needs to call it.
validateExpectedAgainstActual should be private, only TestDriver uses it
Good work, thanks for your contribution and sorry about out slow response, we look forward to more of our your contributions
> 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, 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