On Fri, Aug 22, 2008 at 9:20 AM, Brian Eaton <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 21, 2008 at 6:06 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > I think you misunderstood the purpose of ServletTestFixture. Nothing > should > > have been inheriting from the fixtures, and ServletTestFixture was > created > > to replace the things that had been inheriting from HttpTestFixture. > > 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. > > > It might help to give an example or two of what you'd like to see in a > test case. Maybe pick one of the classes extending GadgetTestFixture > or ServletTestFixture and describe what you'd like it to do instead? > > IMHO, the best test cases don't use any fixtures at all, they've got > simple enough dependencies that they can do the injection themselves. > If test cases are too complex for that, then they need to have access > to a simple set of fixtures. If we've got multiple fixtures in the > same test case each attempting to mock the same object in different > ways, that's bound to be confusing. 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.
