[Webtest] Re: Global page validation tests
Marc Guillemot <email@example.com>
Fri, 27 Oct 2006 08:00:06 +0200
I see here 2 interesting issues:
- recurrent check that should occur on each new page. Currently the only
way to do that is to included (for instance with an entity) the
verification checks each time when a new response is received.
This works perfectly and is flexible but it's a bit cumbersome and it's
too easy to forget the verification on some pages. Ideally WebTest
should provide a way to specify (verification) steps that have to be
performed each time a new response has been received. I've had this idea
on the beginning of the year but WebTest internal didn't provide the
possibility to (easily) implement this. Since the refactoring post 2.1
this should now be possible and the most difficult will be... to find a
good name for this. Suggestions are welcome.
- I think too that it would be helpful to generalize the system of
warnings currently used for the html parser messages. This becomes
important as htmlunit becomes more tolerant what may be useful on one
side but brings less help creating completely correct web applications.
Nate Oster wrote:
> On my project, we have a set of global tests that should be true on
> every page. For example, every page should have a standard disclaimer
> at the bottom, and a set of admin links. In addition, we have negative
> tests to ensure compliance with our UI standards, like that every table
> column must have an HTML label, or that every Data Table should be in a
> DIV of a certain class.
> What do you think is the best way to OPTIONALLY run a standard set of
> WebTest steps (mostly VerifyXPath steps) against every page in the
> application? I tried <reportSite>, but of course that’s simply a spider
> that can only reach statically linked pages. I’d prefer to simply “turn
> on” the validation steps and have them run as part of our regular
> functional test suites.
> In addition, it would be ideal if we could avoid failing the test script
> if one of the expressions was violated, but instead simply log it as a
> warning (much like warnings about XHTML compatibility is done now).
> That way, you won’t have to fix an issue in order to get the complete
> set of validation failures as part of your regular test cycles.
> What do you think?
> Nate Oster