Sometimes we need to find alternative ways to interact with a page becuase buttons might need more than a click.
“I clicked on that, why didn’t the click work!”
I faced the challenge of using Selenium to automate a web application that stubbornly resisted my attempts to automate it.
No need to know the name of the application in question, but the basic situation I faced involved a form with a ‘save’ button.
I used Selenium to fill in the details in the form and click the save button.
When I run Selenium I can see the text I enter on the form, and when the ‘save’ gets a click the little Ajax image for ‘saving’ appears, but when I check the data saved - nothing got saved.
I struggled with this on my own for a while then paired with someone to help.
Pairing brings a number of benefits:
- 2 minds instead of one
- you engage in the ‘ah!’ moments that only happen when you explain something to others
- you get a fresh perspective on the problem
So instead of focusing on the ‘save’ event we had a look at the form input fields.
The input fields had a few events - one having an
onblur event. The
onblur event code seemed to suggest that it persisted the form data into an in-memory store which the ‘save’ event then processed. So the problem did not seem to involve the save event - the type command did not trigger an
onblur when it ‘moved’ between fields.
OnBlur fires when you lose focus so we first tried clicking on the other fields to make that happen.
But that didn’t work.
We had to figure out how to fire a particular event for the element.
Selenium-RC used to have a
fireEvent command. We now use
Triggering the Event
With events I typically try to dispatch the event direct to the element first, before trying other elements or the document.
If you experiment with the page in question then you would see that events can fire for different reasons, e.g. we can trigger a blur if we click on the button, then tab away, or click somewhere else.
These work arounds can often be browsers specific, and might lead to intermittent tests if we use them in production code.
So lessons learned for me:
- When testing we need to use the Browser Dev Tools ‘inspect element’ functionality to learn a bit more about the app under test
- Experiment with code in the console to get it working before trying to migrate it into Java e.g.
- Any testing you do, learn the technology that underpins it
- It can help to work with programmers and use their technical knowledge to help
The full source for this is in my Webdriver Java FAQs project:
If you want to learn how to use Selenium WebDriver with Java then check out our online courses.
You will need a Github account to comment. Or you can contact me with your comment.
I reserve the right to delete spam comments e.g. if your comment adds no value and its purpose is simply to create a backlink to another site offering training, or courses, etc.