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. - Paul Adriaan Joubert <adriaan...@gmail.com> wrote on 02/11/2009 20:26:19: > That would be great! And we would need some way of invalidating a > service so that a clean mock would be picked up for a successive test, > i.e something like the per-test scope in testify? I assume a life > cycle service would do the job, but I think then a way of changing the > scope on an existing binding would be required. Also in testify the > per test life-cycle service is strictly per thread, and I have cases > where multi-threaded behaviour is being tested and it would be wrong > to have the services per thread. So two test life-cycle services or > some serious magic would be needed. > > Thanks! > > Adriaan > > 2009/11/2 Howard Lewis Ship <hls...@gmail.com>: > > That's actually a very interesting idea ... I can see implementing > > additional methods on RegistryBuilder that would allow you to supply > > pre-built (i.e., mock) implementations of various services, for the > > express purpose of testing. > > > > On Mon, Nov 2, 2009 at 10:45 AM, Adriaan Joubert <adriaan. > m...@gmail.com> wrote: > >> Hi, > >> > >> We are using T5 IOC in a standalone application and it is great. Most > >> tests we can implement with a few mock classes and instantiating an > >> instance of the implementation of a service. There are however cases > >> where it is easier to use the IOC registry to stitch things together, > >> but only replace some services with mocks (or a suitably configured > >> local instance of a service). Ideally I want to use existing AppModule > >> configuration modules and only extend with a test module. > >> > >> My problem is how to get the registry to return my mock objects when > >> asked for a specific service. It feels like a problem that probably > >> has a simple solution. > >> > >> When using a standalone test module, I've managed to write mock > >> instances into static fields in the TestAppModule, and then return > >> them from ServiceBuilder methods. This works, but is laborious and > >> very ugly. > >> > >> I spent some time picking testify apart, which is great to learn from. > >> However as far as I can see the dependency injector completely ignores > >> the IOC registry and intervenes by injecting objects from its own > >> pool. This has the advantage that it can be initialised after the > >> registry has been started. This is great, but we only use constructor > >> injection, so I don't think this is going to work for us. > >> > >> My next thought is to write the test class into a field in my > >> TestAppModule before starting up the registry. I imagine I can then > >> use a ServiceOverride configuration method to pick out the mock > >> objects I want to use, and provide a custom object locator to return > >> these for specific services. > >> > >> This is still quite ugly and does not deal with the problem of how to > >> handle the situation where objects are recreated in a setup method for > >> every test run. > >> > >> So I thought I'd ask before spending more time on this. Anybody > have any ideas? > >> > >> Thanks, > >> > >> Adriaan --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
