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

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

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

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

Re: testing http server
by 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.

      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.