Timo Rantalaiho wrote:
>
> On Tue, 13 Nov 2007, mclev wrote:
>> 1. Can I use Guice injection in a way that I can test my forms without
>> the
>> need for a test database.
>
> In the little experimentation I've done, I have found that
> the most straightforward way with single components without
> contained guice-depndent components is to set the dependencies
> directly to the fields, without going via Guice.
>
>
I don't know how to do this when my fields are private:
public class PartDetailPage extends WebPage
{
/** Log. */
private static final Log log = LogFactory.getLog(PartDetailPage.class);
@Inject
private PartDAO partDao;
...
}
Am I missing something?
Timo Rantalaiho wrote:
>
>
> This is unconventional as far as I know. Normally you would
> not extend WicketTester but maybe provide a testing subclass
> of your APplication to it and just make WicketTester use
> that (in 1.3, I think that in 1.2 this was more limited).
> Even that is not strictly needed as you can always add
> custom IComponentInstantiationListeners to any APplication,
> including DummyWebApplication that WicketTester uses by
> default.
>
>
Yes, this is much better than my approach. And since I have already
extended the DummyApplication (to "suspend" response processing on submit --
see http://www.nabble.com/forum/ViewPost.jtp?post=13757593&framed=y my
second post ) so now I have:
public class GuiceTestingWebApplication extends TestingWebApplication {
private Module[] modules;
public GuiceTestingWebApplication(Module[] modules){
this.modules = modules;
}
@Override
public void init(){
super.init();
GuiceComponentInjector gci = new GuiceComponentInjector(this,
modules);
addComponentInstantiationListener(gci);
}
}
Timo Rantalaiho wrote:
>
>
> Rendering the page causes some overhead (WicketTester tests
> seem to be a bit slower that orthodox unit tests, and XML
> parsing has shown up in some profiling we did a while back)
> but for me the added benefit of simplicity and automatic
> checking of matching component hierarchy in Java and HTML
> has outweighed the cost.
>
> Still your approach is academically very interesting :)
>
Well, yes I do think that my approach is actually more "academically"
correct since I am attempting to test that my page (and only my page -- this
is a "unit test") renders properly, and performs as expected on submission.
However my "need" came about in a purely practical case -- my test of
"pageX" was failing because of something in "pageY" (when pageX finished
submission, set the response page to pageY, then the WicketTester went on
and tried to render pageY, which failed).
Timo -- I would like to know what you think of my solution -- again see
http://www.nabble.com/forum/ViewPost.jtp?post=13757593&framed=y my second
post , where I overrode the RequestCycleProcessor to allow a test to suspend
response processing.
Thanks,
Matt Clevenger. (aka mclev)
--
View this message in context:
http://www.nabble.com/Using-the-WicketTester-WITHOUT-rendering-a-response-on-submit-tf4801394.html#a13774035
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
