Re: Automated testing of cgi / perl

Michael Vilain wrote:
In article <1171565491.430048.105110@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
spam@xxxxxxxxxx wrote:

Hello, I have the following situation:

- Existing site with about 18,000 cgi pages.
- Most pages are data driven (fill out form, submit, get results).
Exact results may change from day to day as data get updated.
- Some static html mixed in
- Many pages require authentication. It is a custom in-house
authentication mechanism, but ultimately it stores a temporary session
ID in a session cookie.

I would like to implement automated testing that will:

- Tell me if anything breaks.
- Tell me if a new installation of the same overall site is working
the same as the original (for an upgrade project).
- Tell me if I break anything during maintenance (regression testing)

Can anyone give me some pointers on this? Tool? Overall approach?
Pitfalls? Any clues appreciated.

Larry

I don't know of any tools that can test in a web application environment. The regression testing tool in Unix is expect which is command-line only.
I came across Selenium today, which looks rather useful, and has the advantage of being able to run tests under various browsers. Also worthy of note is jsunit.


With so many pages, there must be an automated test plan. Otherwise, how did the site get so large without detecting and fixing bugs? Or was that what your customers are for?

You can write perl code that uses HTML CPAN libraries to access pages, pretending to be a client. Said connection can input information into fields, even store cookies for session ID between pages.
As an addendum to this:

Test::WWW::Mechanize

would be my first port of call.


If you don't already have an automated testing environment for your web application, it's rather late to start developing one.
He's probably inherited a large and rather crufty application and wants to make sure nothing breaks as he tries to knock it into shape. Best of luck :)

Mark
.

Relevant Pages

  • Re: Reality Check: Session Hijacking
    ... The user is always challenged when he starts to use a secure app, ... And NOT from the session. ... rest of the http response, so he also has the required post data. ... > exposes his session cookie over unencrypted http. ...
    (comp.lang.php)
  • Re: Where is SID?
    ... > and SID echoes as an empty string. ... server, and you'll see the session cookie being set, ... an appropriate session cookie. ...
    (comp.lang.php)
  • Re: seeing who is using the site..
    ... If you demand them to log in, you know WHO they are, as opposed to unknown visitors that happen to start a session with your site. ... If you store the session in a db, they will get deleted after that timeout has expired. ... A browser keeps a session cookie untill *all* instances of that browser is closed. ...
    (comp.lang.php)
  • Re: seeing who is using the site..
    ... If you demand them to log in, you know WHO they are, as opposed to unknown visitors that happen to start a session with your site. ... A browser keeps a session cookie untill *all* instances of that browser is closed. ... After that your browser holding a PHPSESSID is invalid and the session file on the server will get deleted sooner or later. ...
    (comp.lang.php)
  • Re: seeing who is using the site..
    ... course happily start a session anyway. ... That is why session timeout, eg after half an hour of no activity. ... untill *all* instances of that browser is closed. ... with the same session cookie. ...
    (comp.lang.php)