FYI - looking at the current EasyMockTestCase - typically an easier
code pattern than:
EasyMock.verify(mocks.toArray());
... is to create a single IMocksControl, either strict or not, create
all mocks off that, and just call replay()/verify() on the control.
This also has the advantage of (if you choose a strict control)
letting you verify order among all the mocks, not just within in each
mock.
On Fri, Aug 22, 2008 at 10:36 AM, Brian Eaton <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 22, 2008 at 10:26 AM, Kevin Brown <[EMAIL PROTECTED]> wrote:
>>> Yep, I misunderstood. Why shouldn't things inherit from test
>>> fixtures? It prevents duplicate sets of mocks and repeated calls to
>>> replay() and verify().
>>
>> All the mocks were contained in the fixtures, and the tests act on those.
>
> OK, now I'm really confused. That's incredibly close to what is
> checked in now, the only difference is that test cases can add new
> mocks without needing to remember to call replay() and verify() on
> separate mock collections. Are you suggesting that no test case
> should declare its own mocks, instead new mocks should be added at the
> fixture level?
>
> See UrlGeneratorTest for an example of a class that adds one mock to
> the overall set. Would you prefer that the GadgetContext mock was
> moved up into GadgetTestFixture?
>
>> Yes, the problem with the old rendering pipeline is the highly coupled
>> dependencies. As that pipeline is cleaned up and refactored into smaller
>> components, the need for the complex fixtures should be eliminated.
>
> OK, we'll get there eventually.
>
