in reply to Re^6: Using Perl to Test a Web App that uses Javascript
in thread Using Perl to Test a Web App that uses Javascript

Do you render the HTML and examine the screen as part of your test suite? If not, why would you execute the JavaScript?

Pretty much everyone verifies HTML by comparing it to a known good output with regexes or the like. There's no reason JavaScript can't be treated the same way.

Testing the actual quality of the JavaScript and HTML is a separate task which is typically done manually by live people who load it up on different platforms and look at it. Although it sounds theoretically possible to automate JavaScript testing to the point that one could tell whether or not the code produces errors, I've never heard of anyone really doing it with an automated test.

  • Comment on Re^7: Using Perl to Test a Web App that uses Javascript

Replies are listed 'Best First'.
Re^8: Using Perl to Test a Web App that uses Javascript
by diotalevi (Canon) on Jun 08, 2004 at 20:23 UTC

    You test JavaScript by seeing that it compares to some known value? I suppose that is important if you are generating the JavaScript but normally I'm testing that functions perform as expected. My testing usually involves make sure that stuff like the following performs correctly, that other functions meant to twiddle form values do the right thing, etc. The thing *is* an application and I'd normally expect tests to run in the context of the browser.

    Thinking further ... this implies two separate modes of testing. One mode for testing the server portion of the application. It would be a normal WWW::Mechanise script, probably after using something like HTTP::Recorder to get the expected interaction down. Another mode would script a client to validate that it executed the application as expected. So maybe the client runs against the server, maybe it runs against a dummy server provided by the test, whatever.

    Thanks for the thoughts perrin. I'd previously thought it would be a good idea to give JavaScript abilities to WWW::Mechanize but what is really more appropriate is to take HTML-handling functionality away from WWW::Mechanize so it is only a HTTP thing and then script a browser to do all the other testing.

    Read more... (6 kB)
[reply]
[d/l]
      The ability to drive JavaScript input from Perl would begin to make Perl a very attractive competitor to the fiendishly expensive Mercury WinRunner and Rational Robot.

      Add support for easy manipulation of iframes/frames, and you'd put serious pressure on Mercury and Rational.
[reply]
        The ability to drive JavaScript input from Perl would begin to make Perl a very attractive competitor to the
        And it already exists:

        MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
        I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
        ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]
        Frames? I think you are still confusing client and server. What is there to test about frames that can't be tested with HTTP::Recorder? That they look good?
[reply]

In Section Seekers of Perl Wisdom