Cheers, that's pretty much what I'd figured. It's interesting though
trying to test that *just* things are wired up correctly in the
servlet without overlapping too much with the unit tests you describe.

Thanks again :)

Toby


On 3 Aug 2009, at 19:28, Nat Pryce <nat.pryce@(protected):

> The servlet API is clunky.
>
> I prefercto treat servlets as a thin-as-possible layer between the
> HTTP server and my code, which has objects with real constructors and
> clear dependencies. I unit test those objects and write integration
> tests to ensure that the webapp initialises and hooks them up
> correctly.
>
> Even better, I find, is not to stick too closely to the servlet API
> and just use the Jetty HTTP engine embedded in simple main app. That
> allows me to write servlets that have constructors and avoid the whole
> servlet-context/web-app-lifecycle-listener mess.
>
> --Nat
>
> On Monday, August 3, 2009, Toby <toby.weston@(protected):
>> Hello,
>>
>> Probably a silly question really but what's the preferred way to
>> set dependencies on a servlet so they can be mocked? Usually, I'd
>> set them on the constructor of some object and have the servlet
>> delegate to that object but I find myself writing an integration
>> type test where the servlet itself is being tested... I'm assuming
>> you'd set any configuration (ie the dependancies) on the servlet
>> context and mock some servlet API call to return the mocked
>> dependency? I'm wondering if I've forgotten some nifty trick though
>> as that just seems clunky!
>>
>> Cheers,
>> --
>> Toby
>>
>
> --
> http://www.natpryce.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email