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.
