On Fri, 20 Jul 2007, Craig Lenzen wrote:
And how are you overriding the goToPageB method in the test? Using
WicketTester you never actually create an instance of PageB, that is you as
the developer.
Like this, in 1.3
wicket.startPage(new ITestPageSource(){
public Page
I've come up with a possible solution to this issue or at least a start that
can be discussed a bit more.
My solution is to implement my own implementation of wicket's IPageFactory.
This implementation is really just a wrapper around the default one since
the default one is final.
I then
Tim,
And how are you overriding the goToPageB method in the test? Using
WicketTester you never actually create an instance of PageB, that is you as
the developer.
-Craig
Timo Rantalaiho wrote:
On Tue, 17 Jul 2007, Ingram Chen wrote:
We also suffer the same issues here. But due to
On Tue, 17 Jul 2007, Ingram Chen wrote:
We also suffer the same issues here. But due to unmanaged nature of Wicket,
there is no chance to intercept construction of page B unless you build your
own factory for page.
class Page A {
MyFactory myFactory ;
public Page A {
* Craig Lenzen:
I'm looking for some feedback as to an issue I'm having with the
WicketTester. To start I'd like to point out that I'm using
Spring and injecting my pages / components via the wicket spring
project's component injector.
Here is the situation, I have page A that has a
The Spring injection is setup properly, for functional use and unit testing.
The issue is, is that I should not have to worry about setting up page B
dependencies when I'm testing page A. I should only have to worry about
that dependency when it comes to actually testing page B.
-Craig
I guess saying I don't care about page B is a little harsh. I care that
when the link is clicked that the next page to be rendered is page B, what I
don't care about is that page B was actually rendered.
So I don't think mocking up the page is the proper solution. Instead I
would want to mock
This concept might work ok if the link only goes to the same page every time
it is clicked, but what if the link goes to a different page depending on
presentation logic with in the page. I think you would be SOL in that case.
-Craig
Ingram Chen-2 wrote:
We also suffer the same issues
We also suffer the same issues here. But due to unmanaged nature of Wicket,
there is no chance to intercept construction of page B unless you build your
own factory for page.
class Page A {
MyFactory myFactory ;
public Page A {
add(new Link(toBPage) {
But due to unmanaged nature of Wicket, there is no chance to intercept
construction of page B unless you build your own factory for page.
Not entirely true as there is IComponentInstantiationListener.
Eelco
-
This SF.net
The problem here is that fact that I'm only testing page A, I don't care
about the functionality of page B nor which services it might call. So is
there a better way? Is there a way that you can mock the rendering of page
B? Has anyone else ran into this issue and or questioned it, or has
11 matches
Mail list logo
