Ok, thanks for your reply Igor!
Regards,
Vincent
On May 12, 2010, at 17:44, Igor Vaynberg <igor.vaynb...@gmail.com>
wrote:
i would go with 2
the problem here is that wicket tester is designed to render the
pages, if it didnt then all you would have to do is make sure that a
pagerequesttarget with the correct page was set on the request cycle.
-igor
On Wed, May 12, 2010 at 1:06 AM, Vincent Lussenburg
<vincent.lussenb...@gmail.com> wrote:
Hi all,
I'm sending this page to check if I've drawn the correct
conclusions on
testing wicket pages in isolation.
The situation is as follows: we have a number of pages that work on
the same
model object. The object is passed from page to page in page
transitions. So
for example, when the 'next' button is pressed, setResponsePage(new
NextPage(modelObject)); is called. The constructor of these pages
explicitly
require the typed object.
We're testing these pages using WicketTester. What happens now is
that if an
action is done to invoke the next page, that page is also constructed
(normal POJO behavior) and rendered (by WicketTester). This means
we have to
prepare our mocks for any code executed in the next page as well.
That
violates the DRY principle, we'd rather test the page in isolation
and only
check that the page is constructed with the correct argument. The
following
solutions came to mind:
1) Change the constructor to accept PageParameters instead in which
we put
the model object we wish to pass and use the IPageFactory to
construct the
page. In tests, we can mock the IPageFactory to expect the call and
return a
DummyHomePage instead. Downside is that production code is less
obvious -
contracts are less strict.
2) Place the code that creates the pages in a protected method we can
override in test mode. So, in production code we have:
WebPage createNextPage(final ModelObject modelObject) {
return new NextPage(orderModel.getObject());
}
In test code we have:
class TestableNextPage extends NextPage {
[....]
@Override
WebPage createNextPage(final ModelObject modelObject) {
nextPageWasCalled = true;
return new DummyHomePage();
}
}
3) Create our own PageFactory specialization that supports
createPage(Class<? extends Page> pageClass, Object...
constructorParameters))... but I have a feeling that there's a
reason it's
not included in Wicket.
I find solution 2) now least intrusive in production code so we're
using
this approach, currently but I'm not overly enthusiastic about it.
Are there any options I'm overlooking?
Thanks for your insights,
Vincent.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
