Hi Bryan,
You do not say whether you're interested in unit testing or functional
testing of these web services. If you're purely interested in functional
testing (i.e. you do not care about how the web services are
implemented), then you should surely using something like HttpUnit
instead of Cactus.
With Cactus you're able to:
1/ send XML in your requests
2/ performs some assertions on the server side (like verifying objects
are correctly put in the HTTP session, etc)
3/ verify returned XML in the HTTP response
It's quite easy to do:
public MyTest extends ServletTestCase
{
public void beginXXX(WebRequest request)
{
// Create your XML here
[...]
request.setUserData(xmlInputStream);
}
public void testXXX()
{
MyServlet servlet = new MyServlet();
servlet.init(config);
// Call your method to test on your servlet. For example, doGet
servlet.doGet(request, response);
// perform server-side asserts
}
public void endXXX(WebResponse response) <-- use HttpUnit WebResponse
here
{
// perform asserts on returned response.
}
}
Hope it helps,
-Vincent
> -----Original Message-----
> From: Thompson, Bryan B. [mailto:[EMAIL PROTECTED]
> Sent: 23 January 2004 19:47
> To: [EMAIL PROTECTED]
> Cc: Brad Bebee (E-mail)
> Subject: Testing REST web service
>
> Hello,
>
> I am looking for a place to begin in testing some "REST web services."
> These
> are
> basically services that are accessed using HTTP an updating the
"state" of
> the
> resource by shipping XML documents. This is close the the problem of
> testing
> a web site, but the concern is with XML and the services use the HTTP
> methods
> in slightly different ways.
>
> GET - return the XML of the resource.
> POST - create an XML resource.
> PUT - update an XML resource.
> DELETE - destroy an XML resource.
>
> I think that the best way to write these tests is probably to use any
HTTP
> client
> library and simply issue the appropriate HTTP requests and examine the
> HTTP
> responses.
> This would be testing from the perspective of the client. This seems
the
> "right"
> testing level since it lets us test the actual performance of the
service
> as
> perceived
> by a client that is accessing the service just as the service would be
> used
> "live".
>
> I'm not sure whether or not I get the same effect when using cactus
since
> I
> do
> not really understand the relationship between the container, the
various
> redirectors employed and the tests. However, it does look like the
cactus
> tests
> tend to be running on the server while I am after tests that run on
the
> client in
> coordination with a test deployment of the services under test.
>
> This is a maven project, so there is an existing integration to
support
> junit and
> cactus as part of the project management environment. I am trying to
> figure
> out
> whether or not I can leverage the setup of the servlet container by
> cactus,
> just
> use cactus, need to write an integration with cactus for this purpose,
or
> can't
> use cactus and need to back down to plain Junit and manage the servlet
> container
> myself, e.g., in maven preGoal and postGoal clauses.
>
> It does not look like the WebRequest is directly suited to testing
such
> services.
> For example, it does not support PUT and DELETE. Also, the HttpUnit
does
> not
> appear
> to be aimed at testing such XML services.
>
> I was wondering if anyone had suggestions as to how I might approach
this
> testing
> problem.
>
> Thanks,
>
> -bryan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
