Yeah This is incredible useful. In T4 I set up something similar. We have a MockBuilderFactory that inserts a proxy that can be switched between a mock and the real object. This offers these benefits:
1. Production configuration is the same as the test configuration. ( reduces "the tests pass but it breaks in production cases" ) 2. Tests can switch back and forth between the "real" service and the mock service. Would be great if T5 had the same capability! Patrick Moore Amplafi http://amplafi.com 650-207-9792 "Put your front window on your front page" corp blog : http://amplafi.com/blog personal blog : http://www.sworddance.com/blog On Sat, Nov 7, 2009 at 4:57 AM, Adriaan Joubert <[email protected]>wrote: > Hi Paul, > > thanks a lot for your mail. Not having to rebuild the registry between > tests is indeed a major consideration. I like your idea of a special > proxy that can be 'cleaned' and refreshed from a pool. > > I do not need the multi-threaded testing on our web applications right > now. I mainly need it for our fat-client java app where we use > constructor injection. I'm happy to put in an issue for you to track > it if you like, but do not want you to feel obliged to spend time on > it now. If a more comprehensive tapestry wide solution could be built > that should solve this problem as well. > > Thanks! > > Adriaan > > 2009/11/3 Paul Field <[email protected]>: > > Funnily enough I was thinking of something very similar for Testify. I > was > > imagining a "from-tests" scope - which is basically like the per-test > > scope except that the service proxies look up their implementations from > > the pool of objects populated by the @ForComponents annotations. (Which > > probably means the annotations need a name change to @ForTapestry or > > something like that). > > > > The important thing for me is that the same IOC can be used from > > test-to-test but with different mock/fake implementations being created > > each time. When I was originally playing with testing ideas before > > Testify, I had an IOC builder that could plug-in pre-created objects (I > > think similar to what Howard is suggesting) but you get an overhead in > > recreating the IOC for every test. testify is deliberately designed to > > avoid overheads like that so your tests go fast. > > > > Actually, thinking about it, we might want a special RegistryBuilder that > > creates *all* services with a special proxy that looks for an override > > implementation in some dynamic pool of objects - it returns the override > > implementation if it finds it in the pool, otherwise it returns the > normal > > implementation as defined in the module. That way we can change > > implementations dynamically at runtime for any service in any module - > > cool 8-) - This sound too good, so there's probably some implications I > > haven't thought of... > > > > BTW Adriann - if you want per-test scope to span threads, I think I can > > make that happen. Could you pop an issue into the Testify JIRA to remind > > me? ( http://tapestry.formos.com/jira/browse/TESTIFY ) Unfortunately, I > > don't have a lot of time at the moment, but I will get round to it > > eventually. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
