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.

In more complex scenarios where you don't have control over 
the creation of all guice-dependent components you can easily
add a custom GuiceComponentInstantiationListener to your 
Application in the test case after creating the Application but
before creating the component under test.

> I figured out how to extend the WicketTester to do Guice injection (pretty
> simple) with a little playing around. Then I was able to mock my DAO (using
> JMock) which then gets injected by Guice via my GuiceWicketTester. This is
> great: my tests can run without a backend DB.

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.

> So, call me crazy, but it occurs to me that it would be nice if I could
> "unit test" just my page, verifying that when the code in my page finishes
> executing everything is what I expect. I don't really care if the response
> page renders properly (I'll test that in a unit test for that page), I just
> want to know that the logic in my page in sending off to the new page.

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 :)

BTW, if you're interested in testing and use jMock you 
might want to check out JDave and its excellent Wicket
support, http://www.jdave.org/ .

Best wishes,
Timo

-- 
Timo Rantalaiho           
Reaktor Innovations Oy    <URL: http://www.ri.fi/ >

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to