Selenium IDE and ASP.NET validators
After reading Jess Tedder's praise of Selenium IDE, I went to give it a try. I liked it, thought it was very easy to use and very effective.
There were two problems I had with it: one, that there doesn't appear to be a way to stop a test once it is in progress without closing the IDE (a problem if you accidentally get yourself into a wait state for something that will never happen), and two, that there doesn't seem to be a straightforward way to test for the appearance of ASP.NET validator control indicators and messages on the page.
Validator indicators and messages are rendered on the page, but initially have their style.visibility attribute set to hidden. Indicators appear at the site of the validator control in the page, while messages are commonly dynamically collected displayed in validation summary controls, elsewhere on the page. Selenium has methods to test for the presence of text on a page, but since the messages and indicators are indeed on the page but not necessarily visible, you get a lot of false positives. I tried using methods that looked for attributes of specific elements, but ran into problems because it isn't always possible to predict what the id will wind up being for a control on an ASP.NET page, depending on what it's nested in and how the markup was generated. Indeed, some controls (like the <li> error message elements that are added to validation summary controls during validation) don't even get their own ids. Finding the control by its location rather than its id can be problematic in ASP.NET because since the error messages are added dynamically, you don't necessarily know where in the sequence the list entry with your message will be.*
I'm sure eventually someone will write a Selenium extension that will take care of this -- a text-on-page test that tests for the visibility of the text. It would be nice if it also allowed expressions for the search text. I might even try it myself once I get past my home programming backlog.
* Yes, ideally you'll know exactly which messages to expect and can predict where in the sequence the message you're testing for will fall. But the test you're running might be just for one function generating one message, and not concerned with nor wishing to specify what other validation messages might be visible.
There were two problems I had with it: one, that there doesn't appear to be a way to stop a test once it is in progress without closing the IDE (a problem if you accidentally get yourself into a wait state for something that will never happen), and two, that there doesn't seem to be a straightforward way to test for the appearance of ASP.NET validator control indicators and messages on the page.
Validator indicators and messages are rendered on the page, but initially have their style.visibility attribute set to hidden. Indicators appear at the site of the validator control in the page, while messages are commonly dynamically collected displayed in validation summary controls, elsewhere on the page. Selenium has methods to test for the presence of text on a page, but since the messages and indicators are indeed on the page but not necessarily visible, you get a lot of false positives. I tried using methods that looked for attributes of specific elements, but ran into problems because it isn't always possible to predict what the id will wind up being for a control on an ASP.NET page, depending on what it's nested in and how the markup was generated. Indeed, some controls (like the <li> error message elements that are added to validation summary controls during validation) don't even get their own ids. Finding the control by its location rather than its id can be problematic in ASP.NET because since the error messages are added dynamically, you don't necessarily know where in the sequence the list entry with your message will be.*
I'm sure eventually someone will write a Selenium extension that will take care of this -- a text-on-page test that tests for the visibility of the text. It would be nice if it also allowed expressions for the search text. I might even try it myself once I get past my home programming backlog.
* Yes, ideally you'll know exactly which messages to expect and can predict where in the sequence the message you're testing for will fall. But the test you're running might be just for one function generating one message, and not concerned with nor wishing to specify what other validation messages might be visible.
posted by Ann at 12:56 PM
129 comments
