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? The fixture had utility methods for generating the mocks and adding them to a control. The tests should only ever have to call fixture.replay() once, and all their mocks should be generated using fixture.mock(). Ideally the mock creation would be handled by a lower level object (GadgetTestFixture), and the ServletTestFixture would only add servlet-specific things, like the response recorder. As pipeline improvements are made, I'd like to remove the pre-baked mocks from ServletTestFixture as well. Inheriting from the fixture causes all sorts of other oddities. Adding explicit calls to fixture.mock, fixture.replay, etc. avoids these (along with the usual arguments for favoring composition over inheritance). > > > 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. >
