I would have thought that the testing would have to also validate that non-HTTP-interacting parts of the JavaScript also functioned. I'd want to know that things like for ( var ix = 0; ix < stuff.length; ix++ ) document.write( stuff[ ix ] ); had output the correct data, etc. There is more to testing this sort of thing than just what passes between the client and the server. | [reply]
[d/l] |
There is more to testing this sort of thing than just what passes between the client and the server.
No, there isn't, unless you are testing a web browser. All that matters when testing a server is that you send in a certain request and get back a certain response. If you really want to check that the correct JavaScript was returned, you can compare it to a known correct sample. It's no different from checking any other content in an HTTP reply.
| [reply] |
I would normally expect that test would not be solely about the state changes the server but also on the information being reported to the user. Since the web browser is the client, the test should include validation that the correct thing happens on the client. I can appreciate that from one point of view the client can be treated as black box for generating HTTP traffic but from another - it is just another major node on which to validate the state changes. On a Win32 machine I suppose you'd want to script the browser with COM. What would be the equivalent to script stuff like Mozilla on non-Win32 machines? At work, our supported browsers are Internet Explorer 5.5 SP2 and Netscape Navigator 4.78. My application testing always has to extend to validating that the browser is doing the correct thing with whatever the server gave it. I imagine that your application testing is similar except with more supported browsers. At the moment, this means that all the testing is highly manual and not scripted at all. Its a bummer but given the lack of hooks into the browsers being tested it isn't something that we can change.
| [reply] |