The Selenium IDE has been around since 2006 yet doesn’t get the acclaim it deserves. To be honest, the Selenium IDE had several shortcomings that prevented it from ever becoming a legitimate automation tool. Flaky tests due to poor element identification possibly being the biggest drawback to the IDE, but other weaknesses emerged as well including no cross-browser support (and no parallelization), no conditional logic, and overall poor support. Thankfully this all changed when the Selenium IDE began being maintained in 2018. With the latest version of the IDE (3.x), the Selenium developers solved the problems listed above and included additional features that make the tool a valuable test asset to web automation.
There are several Selenium IDE tutorials available (both text and video), on how to use the tool, so I won’t get into the details of how to use the IDE here. I will, however, point out the major features of the Selenium IDE that you should know about and why I think the tool deserves more attention as well as…acclaim.
The Command-line Runner - also referred to as the Selenium Side Runner. As mentioned above, one of the pitfalls of the early Selenium IDE was no support for cross-browser testing and no support for parallelization. This has all been solved with the advent of the Command-line Runner where you can now run tests on any browser, in parallel, and on a Grid (without needing to write any code!). To achieve this, users must install the runner as well as the associated browser drivers for local test runs. Currently, Firefox, Chrome, Edge, IE, and Safari are supported and the Selenium IDE has great documentation on how to configure your environment.
Another major limitation of the earlier version of the Selenium IDE was the very flaky element identification process and how brittle it was. Previously the IDE would use one element locator - either XPath or CSS and simply wait for the element. Now the Selenium IDE records multiple locators for each element it interacts with. If one locator fails during playback, the others will be tried until one is successful. For proof of this concept, I recorded a basic test where I verified text as one of my test steps. You can see the IDE captured multiple XPath elements for my target, on top of the original CSS target:
Control Flow, in my opinion, is one of the coolest additions to the IDE and one that filled a significant shortcoming to the tool. With Control Flow, the Selenium IDE includes commands that enable you to add conditional logic and looping to your tests. Now you can execute a command (or set of commands) only when certain conditions are met, or execute commands repeatedly based on pre-defined criteria. This is such a critical aspect of functional testing and one that deserves renewed attention because now you can create smart tests with the IDE, you can test code paths previously unchecked. Here is an example directly from the Selenium IDE documentation illustrating a loop where the ‘times’ command is used to specify the number of iterations:
In addition to this functionality, the IDE offers explicit wait commands that help when the built-in wait strategy of the IDE is insufficient. Instead of simply waiting for an element, users can apply conditions like:
Wait for element editable
Wait for element present
Wait for element visible
Wait for element not editable
Wait for element not present
Wait for element not visible
With these types of features, I consider the Selenium IDE a low-code open-source test automation tool for web applications. The IDE has increased its library of commands, especially concerning the Control Flow conditional logic commands; if, else if, else, times, do, repeat if, while, end. This dramatically increases the number of functional tests that can be created. Add the ability to run cross-browser tests in parallel using the Command-line Runner and you have a tool that is not only practical but scalable. With added test resiliency, where target elements are identified more effectively, and support for the Selenium IDE project is active and current, there is no reason why you shouldn’t be using this tool if you are involved in the SDLC of a web application. The audience for this tool is practically everyone; while there is no requirement for coding it is very helpful if users understand HTML and the DOM. In any event, documentation for the Selenium IDE is very straightforward and easy to understand with lots of relevant examples. The good news is there are plenty of reasons why you should be using the Selenium IDE, more reasons than not, and that deserves some acclaim.