Client Side Testing
Note to myself: unit testing is a great thing and I should do it more, I plan to do it more. But, unit testing is not enough…
What we need for web applications (or complex dynamic web sites if you prefer) would be something like this: the TEST program would act like a regular web browser, executing javascript and all the rest. The main difference with a web browser would be that the TEST program would be scriptable.
You could script it to log in, enter data into forms, perform search requests, check that the requested data appears on the screen, etc… You may even want to compare the generated HTML with a prerecorded excerpt. You may want to tolerate differences like white spaces and may be even non structural tags (ignore spans, styles attributes, etc…)
Of course, you’ll want the TEST program to validate the XHTML output as well as the CSS styles.
Advanced testing would involve sending onclic events to specific objects on the page and see how the javascript behaves.
You’d have different scenarios you could run in sequence to fully test your application.
Even better: you could run multiple scenarios concurently (you’ll need cookie isolated client threads for this) in order to stress load your application and record response times.
God, I gotta stop dreaming about it and find that gem…
Later:
I found a few potentially interesting tools here:
- Puffin Automation Framework. Open Source. [No longer exists]
- QEngine WebTest. Free / Commercial. [No longer exists]
- WAPT Web Application Testing. $ 250.
- WebKing. Commercial.
- OpenLoad. Commercial. [No longer exists]
- Web Performance Load Tester. 499 € +.
- iMacros. $30 - $499.
- eValid [No longer exists]
Mucho later:
Comments from long ago:
Comment from: Lois
But overall, don’t these tools (real and potential) invite extra complexity simply because they can cope with it, as it were…? The analogy might be coding HTML with Dreamweaver, as opposed to doing it by hand - and Dreamweaver is so 20thC.
2005-05-21 12-37