That's a bit more major surgery, but possible. Document all this in an issue and we'll see about getting it implemented!
On Mon, Nov 2, 2009 at 12:26 PM, Adriaan Joubert <adriaan...@gmail.com> wrote: > 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...@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 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me to >> learn how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org