Ah - OK. I don't think there's an easy way to do this at the moment. The 
obvious way is to either use the registry with real dependencies or else 
create a TestModule to fake the dependencies (but you have already 
discounted this approach). 

I've been toying with this kind of functionality for Testify, but there 
are no easy hooks into the registry creation process that would let me do 
it. I do have another ingenious idea though :-)

Paul

Inge Solvoll <inge.tapes...@gmail.com> wrote on 23/02/2010 12:51:18:

> That's what I'm already doing. This time I wanted to test that the 
perthread
> scope of my service worked like it should, that's why I need to do an
> integration test with a real live registry.
> 
> On Tue, Feb 23, 2010 at 12:42 PM, Paul Field <paul.fi...@db.com> wrote:
> 
> > Hi Inge,
> >
> > Testify doesn't support overriding services actually within the 
repository
> > (currently, it make components check for overrides before going to the
> > registry - hence the annotation name @ForComponents).
> >
> > However, would a simple unit test of the service do the trick for you? 
In
> > other words, just create the ModuleOrderProvider by hand, passing in 
the
> > mocked/faked dependencies :
> > ModuleOrderProvider u = new ModuleOrderProviderImpl(settingsFacade);
> >
> > - Paul
> >
> >
> >
> > Inge Solvoll <inge.tapes...@gmail.com> wrote on 23/02/2010 10:42:52:
> >
> > > Ok, so now I need to mock one of the dependencies of a service I'm
> > testing.
> > > I realized that I don't know how to do that when I manually created 
my
> > > registry. I don't want to have a "TestModule" that builds fakes for 
my
> > > external dependencies, in this case it is enough to just mock the
> > service
> > > that provides configuration values.
> > >
> > > Then I tried using testify, like below, but Mockito claims that my
> > > "settings" service is not a mock, so I guess testify isn't built to
> > support
> > > this kind of mocking... Any ideas?
> > >
> > >   @Mock
> > >   @ForComponents
> > >   private SettingsFacade settings;
> > >
> > >   @Test
> > >   public void settingValueIsCachedInThread() {
> > >     when(settings.get(MODULE_ORDER)).thenReturn("module1,module2");
> > >     ModuleOrderProvider u =
> > tester.getService(ModuleOrderProvider.class); //
> > > This service dependes on the SettingsFacade service
> > >     u.getOrder();
> > >     u.getOrder();
> > >     verify(settings.get(MODULE_ORDER), times(1));
> > >   }
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Feb 18, 2010 at 8:58 AM, Ulrich Stärk <u...@spielviel.de> 
wrote:
> > >
> > > > Hmm, you are right.
> > > >
> > > > The builder method for that service would be called multiple times
> > though
> > > > IIRC. Maybe somehow check that then?
> > > >
> > > > Uli
> > > >
> > > > On 17.02.2010 23:32 schrieb Martin Strand:
> > > >
> > > >  Hmm, why different instances? Wouldn't every thread see the same
> > proxy
> > > >> instance?
> > > >>
> > > >> Martin
> > > >>
> > > >> On Wed, 17 Feb 2010 12:17:35 +0100, Ulrich Stärk 
<u...@spielviel.de>
> > > >> wrote:
> > > >>
> > > >>  Querying the registry for the same service from different 
threads
> > > >>> should yield different instances
> > > >>> when using the perthread scope. Just test that. No need for a
> > request
> > > >>> if your service doesn't
> > > >>> require one.
> > > >>>
> > > >>> Uli
> > > >>>
> > > >>> On 17.02.2010 11:42 schrieb Inge Solvoll:
> > > >>>
> > > >>>> Hi!
> > > >>>>
> > > >>>> I recently encountered a bug in one of my services, where it 
had
> > the
> > > >>>> wrong
> > > >>>> scope because I put the scope annotation on the interface 
rather
> > than
> > > >>>> on the
> > > >>>> implementing class. I got the idea that I could manually create 
a
> > T5 IOC
> > > >>>> registry to do integration testing on my services. But how can 
I
> > test
> > > >>>> "perthread" scope on services in the test registry when there 
are
> > no
> > > >>>> real
> > > >>>> requests? I'm assuming this requires mocking the Request object 
in
> > > >>>> some way?
> > > >>>>
> > > >>>> Inge
> > > >>>>
> > > >>>
> > > >> 
---------------------------------------------------------------------
> > > >> 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
> > > >
> > > >
> >
> >
> >
> > ---
> >
> > 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.



---

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.

Reply via email to