I have created a new page with link and then execute:
    DummyBasePage page = new DummyBasePage(action);
    startPage(page);
    clickLink(page.getActionLink());
where action link is a link to another page.
But it is still not working, only DummyBasePage is rendered. Then I look
into WicketTester code and I have found that there are hard coded links'
classes! So the code that is implemented inside a link class is ommited and
its logic is doubled inside WicketTester. It looks to me as a very bad
design (eg. I cannot test other link implementations).

Finally it looks like WicketTester functionality was degraded comparing to
1.4, where application code could be easily testable in WicketTester and in
6.x the code that works ok in real application is not supported by
WicketTester :(.
Could it be possible to add to WicketTester handling such methods from
RequestCycle: setResponsePage(), setResponse()?

--
Daniel




On Wed, Feb 5, 2014 at 1:51 PM, Martin Grigorov <mgrigo...@apache.org>wrote:

> Component#setResponsePage() just delegates to
> RequestCycle#setResponsePage(). So it is the same.
>
> I'm saying that you should not use tester.getRequestCycle().xyz(). I.e. do
> not set the new page in the test code. Set it in the real application code.
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Wed, Feb 5, 2014 at 1:47 PM, Daniel Stoch <daniel.st...@gmail.com>
> wrote:
>
> > In my real application there are calls to
> RequestCycle.setResponsePage(...)
> > which are hidden by more advanced action/navigation framework. So I
> cannot
> > simply replace them by component.setResponsePage().
> > I think that if RequestCycle.setResponsePage(...) is valid for real
> > application, it should also be valid for tests. Am I wrong?
> >
> > --
> > Daniel
> >
> >
> > On Wed, Feb 5, 2014 at 1:14 PM, Martin Grigorov <mgrigo...@apache.org
> > >wrote:
> >
> > > You should not use
> >  tester.getRequestCycle().setResponsePage(DummyBasePage.
> > > class);
> > >
> > > You should do something like:
> > > - in the test code: tester.startPage(Page1.class)
> > > - in your real application code: Page1 or in its components you can use
> > > setResponsePage(Page2.class)
> > > - finally in the test code: tester.assertRenderedPage(Page2.class)
> > >
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > >
> > >
> > > On Wed, Feb 5, 2014 at 12:18 PM, Daniel Stoch <daniel.st...@gmail.com
> > > >wrote:
> > >
> > > > Ok, but what I should call to render DummyBasePage after calling:
> > > >   tester.getRequestCycle().setResponsePage(DummyBasePage.class);
> > > > without making a new request?
> > > >
> > > > --
> > > > Daniel
> > > >
> > > >
> > > > On Wed, Feb 5, 2014 at 12:01 PM, Martin Grigorov <
> mgrigo...@apache.org
> > > > >wrote:
> > > >
> > > > > #processRequest() triggers a new request to the "server"
> > > > > so first the page is rendered, then a new request to the default
> > > > > destination is made, so the home page is rendered and
> > > "lastRenderedPage"
> > > > > changes
> > > > >
> > > > > Martin Grigorov
> > > > > Wicket Training and Consulting
> > > > >
> > > > >
> > > > > On Wed, Feb 5, 2014 at 11:39 AM, Daniel Stoch <
> > daniel.st...@gmail.com
> > > > > >wrote:
> > > > >
> > > > > > One more question: what is a difference between these two calls:
> > > > > >
> > > > > > 1.
> > > > > >     tester.startPage(DummyBasePage.class);
> > > > > >     Result result = tester.isRenderedPage(DummyBasePage.class);
> > > > > >
> > > > > > 2.
> > > > > >
> tester.getRequestCycle().setResponsePage(DummyBasePage.class);
> > > > > >     tester.processRequest();
> > > > > >     Result result = tester.isRenderedPage(DummyBasePage.class);
> > > > > >
> > > > > > The first one works ok (DummyBasePage is rendered), but the
> second
> > > > fails:
> > > > > > HomePage is rendered instead of DummyBasePage. Why?
> > > > > >
> > > > > > --
> > > > > > Daniel
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Feb 5, 2014 at 10:40 AM, Martin Grigorov <
> > > mgrigo...@apache.org
> > > > > > >wrote:
> > > > > >
> > > > > > > Try with tester.setExposeExceptions(false) before making the
> > > request
> > > > to
> > > > > > the
> > > > > > > secured page
> > > > > > >
> > > > > > > Martin Grigorov
> > > > > > > Wicket Training and Consulting
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch <
> > > > daniel.st...@gmail.com
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I'm during migration from Wicket 1.4.x to 6.x and I have the
> > > > > following
> > > > > > > > problem with WicketTester.
> > > > > > > > I have some secured page, during its initialization some kind
> > of
> > > > > > > > AuthorizationException is raised. It should end with
> displaying
> > > > > > standard
> > > > > > > > AccessDeniedPage. Here is a code fragment from test case:
> > > > > > > >
> > > > > > > > 1.4.x:
> > > > > > > >
> RequestCycle.get().setResponsePage(SecuredDummyPage.class);
> > > > > > > >     tester.processRequestCycle(requestCycle);
> > > > > > > >     Result result =
> > > tester.isRenderedPage(AccessDeniedPage.class);
> > > > > > > >     assertFalse(result.getMessage(), result.wasFailed());
> > > > > > > >
> > > > > > > > This test is passed.
> > > > > > > >
> > > > > > > > But in 6.13 the similar test:
> > > > > > > >
> RequestCycle.get().setResponsePage(SecuredDummyPage.class);
> > > > > > > >     tester.processRequest();
> > > > > > > > // or tester.startPage(SecuredDummyPage.class)
> > > > > > > >     Result result =
> > > tester.isRenderedPage(AccessDeniedPage.class);
> > > > > > > >     assertFalse(result.getMessage(), result.wasFailed());
> > > > > > > >
> > > > > > > > is not passed. It is end up on this AuthorizationException
> and
> > > > > > > > AccessDeniedPage is not rendered.
> > > > > > > > Should it be rendered or should I have to change my test,
> > because
> > > > in
> > > > > > 6.x
> > > > > > > it
> > > > > > > > works in different way?
> > > > > > > >
> > > > > > > > --
> > > > > > > > Daniel
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to