You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Anatoly Kupriyanov <ka...@gmail.com> on 2012/11/28 21:56:44 UTC
Unit testing for a page
Hi all,
I'm trying to implement a unit test for a page. The unit testing means I
should test one page only.
Suppose I have a page with a link. When I do
wicketTester.clickLink("myLink");
The WicketTester renders another page, the page rendering requires a lot of
other injected dependencies, and the unit test set-up grows too much
making the test fragile. I just want to verify that another page is set as
a response page.
Is it possible to do it? What are the best practices for unit testing of a
wicket application?
--
WBR, Anatoly.
Re: Unit testing for a page
Posted by Anatoly Kupriyanov <ka...@gmail.com>.
On 29 November 2012 16:55, Eric Jablow <er...@gmail.com> wrote:
> > wicketTester.clickLink("myLink");
> >
> > The WicketTester renders another page, the page rendering requires a lot
> of
> > other injected dependencies, and the unit test set-up grows too much
> > making the test fragile. I just want to verify that another page is set
> as
> > a response page.
> >
> > Is it possible to do it? What are the best practices for unit testing of
> a
> > wicket application?
>
> This is actually a good point to improve your application and its tests.
> Use dependency injection to organize your application, say through
> wicket-guice or wicket-cdi. Use an alternative test Guice module to
> build your pages with while testing. So, when you reach the second
> test page, it gets built with low-cost data,
>
It contradicts with the idea of unit tests: test only a small unit,
bringing minimum dependencies. Otherwise a change in one page would break a
lot of other tests. It is significant especially for web-applications,
because usually pages have a lot links between them.
It makes a test run longer, which would cause performance problems for
large test suite.
--
WBR, Anatoly.
Re: Unit testing for a page
Posted by Eric Jablow <er...@gmail.com>.
On Wed, Nov 28, 2012 at 3:56 PM, Anatoly Kupriyanov <ka...@gmail.com> wrote:
> wicketTester.clickLink("myLink");
>
> The WicketTester renders another page, the page rendering requires a lot of
> other injected dependencies, and the unit test set-up grows too much
> making the test fragile. I just want to verify that another page is set as
> a response page.
>
> Is it possible to do it? What are the best practices for unit testing of a
> wicket application?
This is actually a good point to improve your application and its tests.
Use dependency injection to organize your application, say through
wicket-guice or wicket-cdi. Use an alternative test Guice module to
build your pages with while testing. So, when you reach the second
test page, it gets built with low-cost data,
Respectfully,
Eric Jablow
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Unit testing for a page
Posted by Anatoly Kupriyanov <ka...@gmail.com>.
On 29 November 2012 08:03, Martin Grigorov <mg...@apache.org> wrote:
> Hi Anatoly,
>
> You are doing it right.
> To be able to verify that the other page is the response this other page
> have to be properly rendered, otherwise you would receive InternalErrorPage
> instead.
> To render it Wicket uses the normal rendering process so you need all
> prerequisites ...
>
Yes, exactly. I've tried to mock/spy RequestCycle object to verify
setResponsePage calls, however no success, too many dependencies.
> You can use tester#startComponentInPage() to test on component level. But
> this is not what you need.
>
Not sure how could it help me. My aim is to verify that a link on a page
follows to another page if some conditions are met. startComponent doesn't
deal with pages, and also assumes use of clickLink. What's a difference?
--
WBR, Anatoly.
Re: Unit testing for a page
Posted by Martin Grigorov <mg...@apache.org>.
Hi Anatoly,
You are doing it right.
To be able to verify that the other page is the response this other page
have to be properly rendered, otherwise you would receive InternalErrorPage
instead.
To render it Wicket uses the normal rendering process so you need all
prerequisites ...
You can use tester#startComponentInPage() to test on component level. But
this is not what you need.
On Wed, Nov 28, 2012 at 9:56 PM, Anatoly Kupriyanov <ka...@gmail.com>wrote:
> Hi all,
>
> I'm trying to implement a unit test for a page. The unit testing means I
> should test one page only.
> Suppose I have a page with a link. When I do
>
> wicketTester.clickLink("myLink");
>
> The WicketTester renders another page, the page rendering requires a lot of
> other injected dependencies, and the unit test set-up grows too much
> making the test fragile. I just want to verify that another page is set as
> a response page.
>
> Is it possible to do it? What are the best practices for unit testing of a
> wicket application?
>
> --
> WBR, Anatoly.
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>