Thanks anyway :)
I guess integration tests on a real registry will be put on hold for now
then, since the only viable solution is to implement stubs for some
services, which makes me unable to mock and verify their behaviour, which
limits my tests quite a bit...
I find integration testing in Tapestry 5, both pages, components and
services, to be quite hard in general. Our system has a lot of spring beans
injected as well as T5 IOC services, so there is a lot to take care of in my
test registry before I can actually get some testing done on my pages. Lots
of database and filesystem stuff that needs to be mocked/stubbed in a
meaningful and mantainable way. But I'll continue trying to find an approach
that makes sense :)
Inge
On Tue, Feb 23, 2010 at 2:13 PM, Paul Field <paul.fi...@db.com> wrote:
> 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.
>
