“They” should pass a law requiring all titles to utilise alliteration.
I can see why people find it hard to work with WebDriver, particularly people new to the tool. Over the years I have learned to expect constant change from the Selenium toolset. After all, the ongoing betterment of web automation worldwide must continue.
- The API changes. Sometimes it works in this browser sometimes it doesn’t, sometimes a browser upgrade breaks Selenium. Sometimes the version of Selenium has bugs etc. etc.
And throughout all of that, I have used it for production automation, without pulling my hair out too much.
Herein, some approaches I have adopted:
- Assume out of date published web documentation
Learn to read the source code. e.g. I just worked with the ChromeDriver. The code has deprecated Capabilities in favour of ChromeOptions. The documentation only describes the capabilities, the code describes the options. I read the code.
- Get your tests working in multiple browsers
- Create the ability to switch off some tests for certain browsers
I primarily want to test functionality, if I have specific functionality that I can’t check cross browser with Selenium then I’ll do it manually. After all I automate a subset of functionality.
A vital part of working with Selenium involves workarounds. Never assume that one perfect way of doing anything exists. Do it quick and dirty if you need to. Selenium has a habit of making my workarounds redundant on the next update.
- Don’t try and automate everything
“But I really want to check that the div is displayed when Ctrl+Z are pressed down, and that it goes when I key up” – great, then find another way to do it, or add a new library to your toolset.
- If you find a problem, check the forums and bug reports
It may not just happen to you. Other people find problems and report them. Sometimes you will find workarounds in the forum thread. You don’t want to spend hours chasing through your own code when you might have stumbled over a known problem, but one that only impacts a small set of fortunate people like yourself.
- Create an experiment to isolate the problem
If it seems like some people have the problem, but others don’t. Then create the simplest experiment that will demonstrate the problem. This will help you find a workaround. The fastest short term work around I know of involves excluding it from one browser, and running it on another.
Sometimes you might care more than the rest of the world, so either try to fix WebDriver, or find a workaround.
- Check your synchronisation
Many (possibly most) of the problems I encounter in my and other people’s test code relate to synchronisation. Learn to use the WebDriverWait rather than rely on implicit waits. Try your test in debug mode, if it works there, but fails in the build, then investigate it as some sort of synchronisation problem. Try running the test in a loop and see if you can get it to fail, this can help diagnosis.
Many different types of synchronisation problems exist – I include parallel running of tests which interfere with each other, as a synchronisation problem.
- Look for a bug in your test, or the app under test
Don’t stop investigating and fix the blame on WebDriver. People find it easy to do that, and then miss problems of their own making. If your organisation seems to have a unique problem then assume the fault rests with you and investigate fully.