You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-user@jakarta.apache.org by Steve Appling <st...@appling.org> on 2002/09/26 15:21:28 UTC
Multi Step Tests - Better HttpUnit Integration
I find that I frequently need to implement tests that require multiple HTTP request/response round trips to set up the conditions for the test. I have been implementing this by using HttpUnit inside my beginXXX method to make a WebConversation and use an HttpUnit to send requests, check response, send next request, etc. After the multi-request setup is complete I can set up the org.apache.cactus.WebRequest for my real test request that will go to my testXXX method and allow me to make assertions about the resulting state of my servlet in my real container (something I can't do with just HttpUnit).
I would think that multi-request setup would be a typical requirement. Are other people doing something similar - or has this been solved in a different way?
What I would like to see in a future version is better integration with HttpUnit in the beginXXX methods. I very much like the version of the endXXX methods that takes a com.meterware.httpunit.WebResponse. I would like to see a similar version of the beginXXX that takes a com.meterware.httpunit.WebRequest instead of the Cactus one. I am very new to Cactus, so perhaps I am missing something here, but this seems like a useful approach to me. Any input would be appreciated.
RE: Multi Step Tests - Better HttpUnit Integration
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Steve Appling [mailto:steve100@appling.org]
> Sent: 26 September 2002 19:09
> To: Cactus Users List
> Subject: Re: Multi Step Tests - Better HttpUnit Integration
>
> Larry, thanks for taking the time to respond.
>
> ----- Original Message -----
> From: "Larry Tambascio" <lt...@charter.net>
> To: "Cactus Users List" <ca...@jakarta.apache.org>
> Sent: Thursday, September 26, 2002 1:34 PM
> Subject: Re: Multi Step Tests - Better HttpUnit Integration
>
>
> > ... What
> > about those preliminary servlets?? Do you have tests for
> > them?? It seems like there should be a starting servlet
> > that simply needs the container/application up and running
> > (and little else beyond maybe user login info). Start
> > with that. Get a test case for that servlet that
> > initializes the environment, and then move on to the next.
> > You are running your Cactus servlet redirector in the
> > same container as your application, right? Then it should
> > have everything that all the other servlets have available
> > to them.
>
> I started down that road, but that seems to require chaining multiple
test
> cases that depend on being run in a particular group or particular
order.
> I
> have tended to avoid that since I have found that I need to then store
> information in static fields to communicate things like session ids
> between
> tests. This seems to get messy and fragile quickly.
>
> > I don't mean to oversimplify or minimize your plight, but
> > manually setting up the environment can be messy,
> > especially if alot is needed. Your HttpUnit solution
> > could well be the simplest way of setting up the context.
> > That doesn't necessarily make it the best.
>
> You are correct about that. I guess I was really trying to determine
if
> there were some other ways of accomplishing the same thing (sending
> multiple
> requests before my real test case) using just Cactus. I'm new to
Cactus
> and
> this was the only thing I could come up with. I understand this type
of
> testing may be not be considered strictly a unit test, but I believe
it is
> the appropriate type of test for my current situation. If this is a
> common
> requirement for other Cactus users, it might be nice to facilitate
these
> types of requests in a future version. I wanted to see if anyone else
> felt
> a similar need.
>
Although I believe it is better to setup the environment without the
need to execute server code in beginXXX (for different reasons already
mentioned by Larry), I am also open to suggestions... :-)
It seems you think it is easier for you to use HttpUnit to set up the
test. Fine! I can accept that. Cactus is very much user-driven ... If
you can submit a patch that doesn't break the existing API but addes a
new beginXXX signature for example, I would gladly apply it. But I don't
have the time to work on that feature ATM.
On a somewhat different subject, I started thinking a while ago about
using HttpUnit internally in Cactus to make the HTTP connection. I can't
remember the details, but I had to abandon the idea as there some
issues.
Thanks
-Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Multi Step Tests - Better HttpUnit Integration
Posted by Steve Appling <st...@appling.org>.
Larry, thanks for taking the time to respond.
----- Original Message -----
From: "Larry Tambascio" <lt...@charter.net>
To: "Cactus Users List" <ca...@jakarta.apache.org>
Sent: Thursday, September 26, 2002 1:34 PM
Subject: Re: Multi Step Tests - Better HttpUnit Integration
> ... What
> about those preliminary servlets?? Do you have tests for
> them?? It seems like there should be a starting servlet
> that simply needs the container/application up and running
> (and little else beyond maybe user login info). Start
> with that. Get a test case for that servlet that
> initializes the environment, and then move on to the next.
> You are running your Cactus servlet redirector in the
> same container as your application, right? Then it should
> have everything that all the other servlets have available
> to them.
I started down that road, but that seems to require chaining multiple test
cases that depend on being run in a particular group or particular order. I
have tended to avoid that since I have found that I need to then store
information in static fields to communicate things like session ids between
tests. This seems to get messy and fragile quickly.
> I don't mean to oversimplify or minimize your plight, but
> manually setting up the environment can be messy,
> especially if alot is needed. Your HttpUnit solution
> could well be the simplest way of setting up the context.
> That doesn't necessarily make it the best.
You are correct about that. I guess I was really trying to determine if
there were some other ways of accomplishing the same thing (sending multiple
requests before my real test case) using just Cactus. I'm new to Cactus and
this was the only thing I could come up with. I understand this type of
testing may be not be considered strictly a unit test, but I believe it is
the appropriate type of test for my current situation. If this is a common
requirement for other Cactus users, it might be nice to facilitate these
types of requests in a future version. I wanted to see if anyone else felt
a similar need.
Thanks again for your comments.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Multi Step Tests - Better HttpUnit Integration
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Larry Tambascio [mailto:ltambascio@charter.net]
> Sent: 26 September 2002 18:35
> To: Cactus Users List
> Subject: Re: Multi Step Tests - Better HttpUnit Integration
>
> Steve,
>
> See comments below. Hope some of them help, or give you
> ideas. Good luck!!
>
> -Larry
>
> On Thu, 26 Sep 2002 12:07:18 -0400
> "Steve Appling" <st...@appling.org> wrote:
> >What Cactus buys me is the ability to have a test running
> >in the container
> >with an instance of my servlet. After all of the setup
> >(which is what I am
> >using HttpUnit for) I can make asserts about the internal
> >state of my
> >Servlet. I don't have a way of doing this by just
> >looking at the servlet's
> >response with HttpUnit.
>
> Agreed.
>
> >
> >It may be possible to preset the state of my system
> >before this one call,
> >but it would be extremely complicated. The particular
> >servlets under test
> >rely on other parts of the web application being set up.
>
> Wouldn't those be setup within the container on startup?
>
> > Some of those
> >parts are outside of my control and do not have a
> >convenient mechanism to
> >initialize them to a particular state. It seems that the
> >most reliable way
> >of running my test in the actual context that the code
> >will execute under
> >when in production is to actually generate the required
> >pre-requisite
> >requests.
>
> Until one of those other parts changes or breaks, and then
> your test fails. What you're doing is fantastic
> integration or functional testing. It's not unit testing
> your servlet. (Oh, I hope I didn't open the "what is unit
> testing vs. functional testing" can of worms/debate.)
>
> It actually sounds like we're in similar boats, Steve. My
> project has complicated setup. The only way to
> instantiate the controller servlet is through the web-app
> container (Tomcat in my case). When I focused on what I
> minimally needed to test my piece of code, I found that
> there really wasn't as much needed for setup as I had
> feared. I instantiate my operations/actions and required
> beans in the setUp or testXxx methods, and then
> specifically invoke them.
>
> I'm sure there are more differences than similarities,
> however, between our situations. Perhaps some testing
> helper classes could facilitate environment setup?? What
> about those preliminary servlets?? Do you have tests for
> them?? It seems like there should be a starting servlet
> that simply needs the container/application up and running
> (and little else beyond maybe user login info). Start
> with that. Get a test case for that servlet that
> initializes the environment, and then move on to the next.
> You are running your Cactus servlet redirector in the
> same container as your application, right? Then it should
> have everything that all the other servlets have available
> to them.
>
> I don't mean to oversimplify or minimize your plight, but
> manually setting up the environment can be messy,
> especially if alot is needed. Your HttpUnit solution
> could well be the simplest way of setting up the context.
> That doesn't necessarily make it the best.
>
I concur. I would add that code that needs overly complex test code to
set up usually need refactoring. This is one the code smell I always
use: if my unit test for a given method is too long, it usually means
that either my method under test is doing too many things and I need to
refactor it or that it does not obey the Law of Demeter enough (in which
case it also needs refactoring).
-Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Multi Step Tests - Better HttpUnit Integration
Posted by Larry Tambascio <lt...@charter.net>.
Steve,
See comments below. Hope some of them help, or give you
ideas. Good luck!!
-Larry
On Thu, 26 Sep 2002 12:07:18 -0400
"Steve Appling" <st...@appling.org> wrote:
>What Cactus buys me is the ability to have a test running
>in the container
>with an instance of my servlet. After all of the setup
>(which is what I am
>using HttpUnit for) I can make asserts about the internal
>state of my
>Servlet. I don't have a way of doing this by just
>looking at the servlet's
>response with HttpUnit.
Agreed.
>
>It may be possible to preset the state of my system
>before this one call,
>but it would be extremely complicated. The particular
>servlets under test
>rely on other parts of the web application being set up.
Wouldn't those be setup within the container on startup?
> Some of those
>parts are outside of my control and do not have a
>convenient mechanism to
>initialize them to a particular state. It seems that the
>most reliable way
>of running my test in the actual context that the code
>will execute under
>when in production is to actually generate the required
>pre-requisite
>requests.
Until one of those other parts changes or breaks, and then
your test fails. What you're doing is fantastic
integration or functional testing. It's not unit testing
your servlet. (Oh, I hope I didn't open the "what is unit
testing vs. functional testing" can of worms/debate.)
It actually sounds like we're in similar boats, Steve. My
project has complicated setup. The only way to
instantiate the controller servlet is through the web-app
container (Tomcat in my case). When I focused on what I
minimally needed to test my piece of code, I found that
there really wasn't as much needed for setup as I had
feared. I instantiate my operations/actions and required
beans in the setUp or testXxx methods, and then
specifically invoke them.
I'm sure there are more differences than similarities,
however, between our situations. Perhaps some testing
helper classes could facilitate environment setup?? What
about those preliminary servlets?? Do you have tests for
them?? It seems like there should be a starting servlet
that simply needs the container/application up and running
(and little else beyond maybe user login info). Start
with that. Get a test case for that servlet that
initializes the environment, and then move on to the next.
You are running your Cactus servlet redirector in the
same container as your application, right? Then it should
have everything that all the other servlets have available
to them.
I don't mean to oversimplify or minimize your plight, but
manually setting up the environment can be messy,
especially if alot is needed. Your HttpUnit solution
could well be the simplest way of setting up the context.
That doesn't necessarily make it the best.
Sorry I couldn't be of more help.
>
>
>----- Original Message -----
>From: "Larry Tambascio" <lt...@charter.net>
>To: "Cactus Users List" <ca...@jakarta.apache.org>
>Sent: Thursday, September 26, 2002 11:48 AM
>Subject: Re: Multi Step Tests - Better HttpUnit
>Integration
>
>
>> Hi Steve,
>>
>> It sounds to me like what you really need is HttpUnit.
>> I'm unsure what Cactus is buying you. What I have
>> usually done is to setup the session as though all your
>> preceding requests and responses have been made. My
>>guess
>> is that it would take about the same amount of code to
>> setup all the session values as it does to do the
>>HttpUnit
>> web conversation thing. Finding out what those all are
>> could be tedious, but it would make your tests cleaner
>>and
>> faster, IMHO.
>>
>> -Larry
>
>
>
>--
>To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Multi Step Tests - Better HttpUnit Integration
Posted by Vincent Massol <vm...@octo.com>.
Hi Steve,
Have you looked at Mock Objects (http://www.mockobjects.com)? This is
what I use when I need to provide fake objects to replace complex code.
For example, let's imagine that you have a complex object to create that
needs to be present in the HTTP session before the test.
You can easily write a Mock for it (or even better use EasyMock to
automatically generate a mock dynamically) and put the mock in the
session.
What is important to realize is that when you are unit testing a method,
you are really interested in testing this method's code logic and not
other domain object (they will get tested by their own unit tests).
Do you have an example to help us see the issues you are facing?
Thanks
-Vincent
> -----Original Message-----
> From: Steve Appling [mailto:steve100@appling.org]
> Sent: 26 September 2002 17:07
> To: Cactus Users List
> Subject: Re: Multi Step Tests - Better HttpUnit Integration
>
> What Cactus buys me is the ability to have a test running in the
container
> with an instance of my servlet. After all of the setup (which is what
I
> am
> using HttpUnit for) I can make asserts about the internal state of my
> Servlet. I don't have a way of doing this by just looking at the
> servlet's
> response with HttpUnit.
>
> It may be possible to preset the state of my system before this one
call,
> but it would be extremely complicated. The particular servlets under
test
> rely on other parts of the web application being set up. Some of
those
> parts are outside of my control and do not have a convenient mechanism
to
> initialize them to a particular state. It seems that the most
reliable
> way
> of running my test in the actual context that the code will execute
under
> when in production is to actually generate the required pre-requisite
> requests.
>
>
> ----- Original Message -----
> From: "Larry Tambascio" <lt...@charter.net>
> To: "Cactus Users List" <ca...@jakarta.apache.org>
> Sent: Thursday, September 26, 2002 11:48 AM
> Subject: Re: Multi Step Tests - Better HttpUnit Integration
>
>
> > Hi Steve,
> >
> > It sounds to me like what you really need is HttpUnit.
> > I'm unsure what Cactus is buying you. What I have
> > usually done is to setup the session as though all your
> > preceding requests and responses have been made. My guess
> > is that it would take about the same amount of code to
> > setup all the session values as it does to do the HttpUnit
> > web conversation thing. Finding out what those all are
> > could be tedious, but it would make your tests cleaner and
> > faster, IMHO.
> >
> > -Larry
>
>
>
> --
> To unsubscribe, e-mail: <mailto:cactus-user-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:cactus-user-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Multi Step Tests - Better HttpUnit Integration
Posted by Steve Appling <st...@appling.org>.
What Cactus buys me is the ability to have a test running in the container
with an instance of my servlet. After all of the setup (which is what I am
using HttpUnit for) I can make asserts about the internal state of my
Servlet. I don't have a way of doing this by just looking at the servlet's
response with HttpUnit.
It may be possible to preset the state of my system before this one call,
but it would be extremely complicated. The particular servlets under test
rely on other parts of the web application being set up. Some of those
parts are outside of my control and do not have a convenient mechanism to
initialize them to a particular state. It seems that the most reliable way
of running my test in the actual context that the code will execute under
when in production is to actually generate the required pre-requisite
requests.
----- Original Message -----
From: "Larry Tambascio" <lt...@charter.net>
To: "Cactus Users List" <ca...@jakarta.apache.org>
Sent: Thursday, September 26, 2002 11:48 AM
Subject: Re: Multi Step Tests - Better HttpUnit Integration
> Hi Steve,
>
> It sounds to me like what you really need is HttpUnit.
> I'm unsure what Cactus is buying you. What I have
> usually done is to setup the session as though all your
> preceding requests and responses have been made. My guess
> is that it would take about the same amount of code to
> setup all the session values as it does to do the HttpUnit
> web conversation thing. Finding out what those all are
> could be tedious, but it would make your tests cleaner and
> faster, IMHO.
>
> -Larry
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Multi Step Tests - Better HttpUnit Integration
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Larry Tambascio [mailto:ltambascio@charter.net]
> Sent: 26 September 2002 16:49
> To: Cactus Users List
> Subject: Re: Multi Step Tests - Better HttpUnit Integration
>
> Hi Steve,
>
> It sounds to me like what you really need is HttpUnit.
> I'm unsure what Cactus is buying you. What I have
> usually done is to setup the session as though all your
> preceding requests and responses have been made. My guess
> is that it would take about the same amount of code to
> setup all the session values as it does to do the HttpUnit
> web conversation thing. Finding out what those all are
> could be tedious, but it would make your tests cleaner and
> faster, IMHO.
Exactly. We should not forget that Cactus is a *unit* testing tool, i.e.
it gives you the ability to test classes at the method level. It's not
there to unit test your doGet()/doPost() Servlet method as this can also
be done from the outside. It is there to unit test all other methods
using container objects.
Thus, as with every unit test, you need to setup the environment in
which the test will run. For Web environments, this can mean :
- HTTP cookies,
- HTTP parameters
- values in the HTTP session
- etc.
-Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Multi Step Tests - Better HttpUnit Integration
Posted by Larry Tambascio <lt...@charter.net>.
Hi Steve,
It sounds to me like what you really need is HttpUnit.
I'm unsure what Cactus is buying you. What I have
usually done is to setup the session as though all your
preceding requests and responses have been made. My guess
is that it would take about the same amount of code to
setup all the session values as it does to do the HttpUnit
web conversation thing. Finding out what those all are
could be tedious, but it would make your tests cleaner and
faster, IMHO.
-Larry
On Thu, 26 Sep 2002 09:21:28 -0400
"Steve Appling" <st...@appling.org> wrote:
>I find that I frequently need to implement tests that
>require multiple HTTP request/response round trips to set
>up the conditions for the test. I have been implementing
>this by using HttpUnit inside my beginXXX method to make
>a WebConversation and use an HttpUnit to send requests,
>check response, send next request, etc. After the
>multi-request setup is complete I can set up the
>org.apache.cactus.WebRequest for my real test request
>that will go to my testXXX method and allow me to make
>assertions about the resulting state of my servlet in my
>real container (something I can't do with just HttpUnit).
>
>I would think that multi-request setup would be a typical
>requirement. Are other people doing something similar -
>or has this been solved in a different way?
>
>What I would like to see in a future version is better
>integration with HttpUnit in the beginXXX methods. I
>very much like the version of the endXXX methods that
>takes a com.meterware.httpunit.WebResponse. I would like
>to see a similar version of the beginXXX that takes a
>com.meterware.httpunit.WebRequest instead of the Cactus
>one. I am very new to Cactus, so perhaps I am missing
>something here, but this seems like a useful approach to
>me. Any input would be appreciated.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>