Automated testing driving me nuts...

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

Hi, again

To ensure quality of the software i write, i use WWW::Mechanize and httpunit for automated testing.
The problem i face however, is that i use httpunit for the site that handles JavaScript, and WWW::Mechanize for plain simple html-pages. (i like the last since it's perl, and i'm not fond of java.)

However, both methods give me problems for not or bad coping with JavaScript, eg. resetTimeOut functions are not supported.

Right now i'm trying to find the solution to automate my front-end testing, that supports JavaScript.

Please tell me there is a (simple) solution that might help me, i'm sure others have to deal with it as well.
Thanks

*update* ps. anyone have experience with wtr ?

// Example code that gives problems in httpunit, i would not know of a
+ way in perl or any other method...

import com.meterware.httpunit.*;
import junit.framework.*;

public class Ced extends TestCase{

    public static void main( String[] params ) {
        try {
            // create the conversation object which will maintain stat
+e for us
            WebConversation wc = new WebConversation();

            // Obtain the main page on the web site
            WebRequest request = new GetMethodWebRequest( "http://www.
+site.com/cgi-bin/script.pl/12" );
            WebResponse response = wc.getResponse( request );

            // Print the pagesource if needed. 
            // System.out.println( response.getText() );

            // Insert form data 
            WebForm form = response.getFormWithName("LoginForm");
            assertNotNull( "No form found with name 'LoginForm'", form
+ );

            form.setParameter("userid", "username");
            form.setParameter("password","secret");
            
            // Submit the data
            WebLink loginbutton = response.getFirstMatchingLink( WebLi
+nk.MATCH_CONTAINED_TEXT, "Log in");
            response = loginbutton.click();
            
        } catch (Exception e) {
            System.err.println( "Exception: " + e );
        }
    }
}

// This generates errors like: Event 'top.ResetTimeOut();' failed: Typ
+eError: clearTimeout is not a function.
[download]

"We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise." - Larry Wall.

Comment on Automated testing driving me nuts... Download Code

Replies are listed 'Best First'.
Re: Automated testing driving me nuts... by dragonchild (Archbishop) on Jun 13, 2005 at 11:45 UTC
You do understand that the only effective way to test JS is to actually run the browser(s) you intend to support and have the browser's JS engine do whatever you want it to do ... right? There are dozens of ways to do this, from Rational Rose to OLE. But, no - you're not going to be able to test how your JS works from the server. In general, if you think something isn't in Perl, try it out, because it usually is. :-) "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"	[reply]
Re^2: Automated testing driving me nuts... by jbrugger (Parson) on Jun 13, 2005 at 11:51 UTC
Yes, i know, but i only need the testsuite to ignore the commands it isn't aware of, i want to be able to have a set of standard automated tests, to ensure at least minimal working functionality. update Ok, taking into account what you said, right now wtr looks verry promising, you have to code ruby, but i don't think there is a problem with it for anyone who likes perl ;-), and it works directly in your browser (only tested ie for now). I've set-up a simple test in less than 5 minutes that i still wasn't able to do with httpunit... I still have to evaluate Siege as well, but that comes later. "We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise." - Larry Wall.	[reply]
Re^3: Automated testing driving me nuts... by dragonchild (Archbishop) on Jun 13, 2005 at 12:47 UTC
In other words, you want to test a specific subset of your application, where "specific" means "the stuff someone else doesn't support testing". The honest way to do this is have your JS have a ishttpunit flag, similar to the isIE and isNS flags, that will remove all stuff that httpunit doesn't support. Frankly, I think you're going about this the wrong way. On the server, you test the server. So, verify that the JS being generated is correct. Verify that the various Perl components are doing the right thing, both in isolation and together. Then, on your target client machines, run the brower(s) you expect to support through some scripted interface and test that. You cannot test client interactions on the server. Not even a little. You need a client to test client interactions. In general, if you think something isn't in Perl, try it out, because it usually is. :-) "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"	[reply]
Re: Automated testing driving me nuts... by eyepopslikeamosquito (Archbishop) on Jun 13, 2005 at 15:14 UTC
For Windows, there is Win32::IE::Mechanize. I'm not aware of an equivalent for Linux, unfortunately. See also Testing at the browser: a trip report. (Perl, Ruby, etc.).	[reply]
Re: Automated testing driving me nuts... by perrin (Chancellor) on Jun 13, 2005 at 22:38 UTC
The only way to meaningfully test your JavaScript is to get all the operating systems and browsers you intend to support in a room and run it on all of them. Short of that, it probably isn't worth doing more than verifying that the JavaScript you expected to get sent is getting sent. My advice is to test your server-side code with automated testing and leave the JavaScript to the same people who "test" the HTML to see if it looks okay.	[reply]