I have attached a patch that illustrates a very simple application of mock objects to test the JobControl API. JobControl depends on the Job class (in org.apache.hadoop.mapreduce), but its logic is independent of Job's. To unit test JobControl's logic we shouldn't have to run a full MapReduce Job. To do so is time consuming, and introduces more dependencies than are strictly needed. (In some situations it is difficult - or at best awkward - to simulate the condition we are trying to test. E.g. https://issues.apache.org/jira/browse/MAPREDUCE-270?focusedCommentId=12759441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12759441.)
Instead we merely need to check that for various Job behaviours JobControl acts as expected. For example, if a Job succeeds then JobControl should put it in the successful jobs collection. (The test could obviously be expanded to cover failing jobs and dependent jobs, like TestMapReduceJobControl. Also, we still need system level tests that run full MapReduce jobs using the JobControl API - this JIRA is about unit tests.)
The test uses Mockito (http://mockito.org/), a mocking framework which is gaining a lot of traction. The other contenders are jMock (http://www.jmock.org/) and EasyMock (http://easymock.org/, http://code.google.com/p/mockito/wiki/MockitoVSEasyMock). In my opinion, Mockito has the clearest syntax and is easiest to use.
Obviously the patch shows a single test. I propose that the scope of this JIRA is to write a handful of different tests to show different cases (e.g. verification of method invocation, not just stubbing), so we can evaluate the framework for inclusion.