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

Reply via email to