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.
