testing http server

fisher has asked for the wisdom of the Perl Monks concerning the following question:

I have here a web server which generates some dynamic content. The dynamic pages constantly touched by other developers and I finally came to decision to test some critical functionality from outside using simple http client and something like Test::More. So I found Test::WWW::Mechanize but can't figure it out how to

ensure that some URI is closed for unauthorized access. I mean there should be a method to check the HTTP code (401 or 403)
check redirection (HTTP 302) and check its destination url

Maybe there is another test framework for this? Please sugest if so.

Comment on testing http server Select or Download Code

Replies are listed 'Best First'.
Re: testing http server by Anonymous Monk on Jan 15, 2013 at 12:39 UTC
You don't need another testing framework, just read Test::More and use `eval { $mech->get.... }; is( $mech->res->code, 500 );` or some such	[reply] [d/l]
Re: testing http server by locked_user sundialsvc4 (Abbot) on Jan 15, 2013 at 15:51 UTC
In my experience, these two things are two tests among hundreds ... and, since they mostly have to do with proper Apache or nginix configuration, they might not need to be part of your internal testing at all. What you are really most interested in, is that the responses (however requested and received) are correct. I have had most success using Selenium, driven on the client side by Perl scripts. This tool drives an actual browser, through a remote-control interface, and does it from the client side. Interfaces to whatever programming tools might be available on the testing-client (specifically including Perl) are plentiful, so the two computers can work together (in your testing lab) however you best see fit. Obviously, while developers are writing the code, Mechanize-style tests are very convenient “also,” and once again I would not prioritize the HTTP 401/403/302 tests unnecessarily when writing them. I might not include them at all. The configuration of a testing machine, known to be inside the network etc., can legitimately be simpler than the big hairy outside-world would be. You simply want to automate the presenting of inputs to the thing and the evaluation of responses received.
Re^2: testing http server by fisher (Priest) on Jan 15, 2013 at 16:52 UTC
since they mostly have to do with proper Apache or nginix configuration, your assumption is wrong here. I have to deal with multiple instances of this web-server and noone can guarantee the configuration is proper. I want to check this configuration, the availability of common handlers, the closed doors to some insider's data and proper redirection to some known queries.	[reply]