Use getLastResponse().

getRequest() and getResponse() return the ones which will be used for the
next interaction.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Fri, Sep 26, 2014 at 2:04 PM, Thibault Kruse <tibokr...@googlemail.com>
wrote:

> Sorry I just realized I pasted something wrong in my last message. My
> current workaround would be:
>
>
> assertThat(TESTER_SCOPE.getTester().getPreviousResponses().get(0).getStatus())
>                 .isEqualTo(HttpServletResponse.SC_NOT_FOUND);
>
> But that is a bit annoying for us when we reuse a tester a bit,
> because wicketTester.getPreviousResponses().get(0) returns the oldest,
> but we need the most recent one, so something like
> testert.getPreviousResponses().get(testert.getPreviousResponses().size()
> -1).getStatus()).isEqualTo(HttpServletResponse.SC_NOT_FOUND);
>
> which is unwieldy. Or alternatively invoking
> TESTER_SCOPE.getTester().getPreviousResponses().clear();
> before a new rendering attempt. I will probably go for that in those
> places.
>
> On Fri, Sep 26, 2014 at 1:57 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
> > OK. Right.
> > ErrorCodeRequestHandler returns a response with code 404 and then the web
> > container uses the definition in web.xml to get the url for 404 ...
> > There is no web.xml with WicketTester and thus no redirect to /404.html.
> > Your code is good!
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Fri, Sep 26, 2014 at 1:53 PM, Thibault Kruse <
> tibokr...@googlemail.com>
> > wrote:
> >
> >> Hm, so the Error Page itself is does not render during the test
> >> (debugger does not enter constructor at all).
> >>
> >> My Error Page has:
> >>    @Override
> >>     protected void configureResponse(WebResponse response) {
> >>         super.configureResponse(response);
> >>         response.setStatus(HttpServletResponse.SC_NOT_FOUND);
> >>     }
> >>
> >> When the exception is thrown, the thread returns to
> >> RequestCycle.HandlerExecutor.execute(), then runs into the catch
> >> clause of RequestHandlerStack.execute(), upcasting the
> >> AborthWithHttpStatusException to a ReplaceHandlerException, yielding
> >> an ErrorCodeRequestHandler for 404. Then this replacementHandler is
> >> executed using RequestCycle.respond(), ending up in:
> >> ErrorCodeRequestHandler.respond(final IRequestCycle requestCycle) {
> >>         WebResponse webResponse =
> (WebResponse)requestCycle.getResponse();
> >>         webResponse.sendError(errorCode, message);
> >> }
> >>
> >> This comes to MockHttpServletResponse.sendError, where status is set to
> >> 404.
> >>
> >> Then the thread continues with WicketTester.setupNextRequestCycle(),
> >> creating a new MockHttpServletResponse() with status 200, but then
> >> does not render any page at all.
> >> This assert passes:
> >> assertThat(TESTER_SCOPE.getTester().getLastRenderedPage()).isNull();
> >>
> >> So I guess I can do a
> >> assertThat(TESTER_SCOPE.
> >>
> >>
> getTester().getResponse().getStatus()).isEqualTo(HttpServletResponse.SC_NOT_FOUND);
> >>
> >> Not sure whether that's ideal, but it's not too bad.
> >>
> >> On Fri, Sep 26, 2014 at 1:32 PM, Martin Grigorov <mgrigo...@apache.org>
> >> wrote:
> >> > Hi,
> >> >
> >> > I think it is 200 because this is the status code of the error page -
> it
> >> is
> >> > rendered successfully.
> >> > You
> >> > need
> >> org.apache.wicket.util.tester.BaseWicketTester#setFollowRedirects(false)
> >> > if you want to assert the response for MyPage.
> >> >
> >> > Martin Grigorov
> >> > Wicket Training and Consulting
> >> > https://twitter.com/mtgrigorov
> >> >
> >> > On Fri, Sep 26, 2014 at 1:29 PM, Thibault Kruse <
> >> tibokr...@googlemail.com>
> >> > wrote:
> >> >
> >> >> As a follow-up: How can the Http Error code then be checked using
> >> >> WicketTester?
> >> >> Currently, after your suggested change, the browser shows my 404 page
> >> >> and status is 404, but in WicketTester, I get
> >> >>
> >> >> In MyPage.java:
> >> >>
> >> >>     @Override
> >> >>     protected void onInitialize() {
> >> >>         super.onInitialize();
> >> >>         throw new
> >> >> AbortWithHttpErrorCodeException(HttpServletResponse.SC_NOT_FOUND);
> >> >>     }
> >> >>
> >> >> In Test:
> >> >>
> >> >>         TESTER_SCOPE.getTester().startPage(MyPage.class);
> >> >>
> >> >>
> >>
> assertThat(TESTER_SCOPE.getTester().getResponse().getStatus()).isEqualTo(HttpServletResponse.SC_NOT_FOUND);
> >> >>
> >> >> org.junit.ComparisonFailure:
> >> >> Expected :404
> >> >> Actual   :200
> >> >>
> >> >> The Exception is thrown by the Page class in the test (as I see in
> the
> >> >> debugger).
> >> >>
> >> >> On Wed, Sep 10, 2014 at 3:09 PM, Martin Grigorov <
> mgrigo...@apache.org>
> >> >> wrote:
> >> >> > Just throw AbortWithHttpErrorCodeException.
> >> >> > The url will remain the same.
> >> >> >
> >> >> > Martin Grigorov
> >> >> > Wicket Training and Consulting
> >> >> > https://twitter.com/mtgrigorov
> >> >> >
> >> >> > On Wed, Sep 10, 2014 at 3:43 PM, Thibault Kruse <
> >> >> tibokr...@googlemail.com>
> >> >> > wrote:
> >> >> >
> >> >> >> Hi,
> >> >> >>
> >> >> >> we have a page for some resource mounted at /resource/<id>
> >> >> >> When users enter an invalid ID, we want to render a 404 page.
> >> >> >> However, we would like the resulting page not have the original
> url
> >> >> >> with the invalid id (but http status 404).
> >> >> >>
> >> >> >> Is there any obvious easy way to achieve this? Because it seems
> the
> >> >> >> general way in wicket tutorials on 404 pages seem to rely on
> >> >> >> redirecting to a mounted 404 resource, which means the browser
> will
> >> >> >> not display the original invalid URL.
> >> >> >>
> >> >> >> cheers,
> >> >> >>   Thibault
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> 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
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>

Reply via email to