Setting dependencies in servlets

View: New views
3 Messages — Rating Filter:   Alert me  

Setting dependencies in servlets

by diyfiesta :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

Re: Setting dependencies in servlets

by Nat Pryce :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...> wrote:
> 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



Re: Setting dependencies in servlets

by diyfiesta :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...> wrote:

> 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@...> wrote:
>> 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