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
