Testing REST web service

["Thompson, Bryan B." <BR...@saic.com>]

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

RE: Testing REST web service

[Vincent Massol <vm...@pivolis.com>]

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:BRYAN.B.THOMPSON@saic.com]
> Sent: 23 January 2004 19:47
> To: cactus-user@jakarta.apache.org
> 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: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org