I don't think the methods are generic - `getObjectManager` only mocks the `find` method. We can imagine other tests requiring other methods at which point the base test case would start to develop in bizarre ways as we hack it to fit.

Personally I would develop each test in isolation - it doesn't have to be in violation of the DRY principle:

````
$this->getMock('...')->expects($this->exactly(2))
    ->method('find')
    ->with(null, 'blah-foo')
    ->will($this->returnValue($this->document));
````
This code is specific to the test case and is more specific in defining what /should/ happen. For example, I have often found that specifying the number of expected calls reveals inefficient code.

For the composite `ManagerRegistry` I would define the two mock object managers in `setUp` as follows.

````php
public function setUp()
{
    $this->om1 = $this->getMock('ObjectManager');
    $this->om2 = $this->getMock('ObjectManager');
    $this->managerRegistry = $this->getMock('ManagerRegistry'); // or whatever
}

public function testFoobar()
{
    $this->managerRegistry($this->expects($this->once())
        ->method('getManager')
        ->with('foobar')
        ->will($this->returnValue($this->om1));

     $this->om1->expects($this->once())
        ->method('findById')
        ->with('asd-asd')
        ->will($this->returnValue($this->document));

     //.. blah

    $this->contentFoobar->doSomething();
}
````

I think if we made a class which mocked an object manager, we would essentially be writing an implementation of ObjectManager, which would in turn need testing! However there is alot of scope for making things easier for unit tests, see https://github.com/instaclick/ICBaseTestBundle for example - but thats something else...

Anyway, I'm not proposing a solution here :) Just discussing.