A Brief History of Selenium IDE

Beyond “Never get involved in a land war in Asia” -- if there’s a single rule all coders adhere to before any code push, it’s to run a full regression set. Over the past 15 years, I’ve always sought to release code as efficiently as possible, and the sheer time required to test is surprisingly difficult to hyperbolize. No developer truly enjoys spending days coding and running tests before a big release.

Enter Selenium IDE

Now that it’s been announced that Selenium IDE is losing ongoing support, it’s easy to forget that -- just a few years ago -- many developers, including myself, were tantalized by the potential of the XUL extension that promised the figurative holy grail of test creation: tests that could be rapidly recorded in a visual environment, all without the ensuing hassle associated with scripting. The allure was real. I could potentially pawn off the slog that is creating regression tests and have a junior developer or non-technical product manager mind-numbingly and vacuously point-and-click through an entire app with Selenium IDE, spectrally reminiscent of a half-asleep Cheeto-infused teenager mastering Mario Kart for the 100th time; and presto, I’d have testing coverage. 

The Early Days

Common intuition dictates that in an age of automation, there must be a slightly more expedient method for creating tests than manual coding. In 2004, Jason Huggins, one of the forefathers of test automation, shared his story of how he was testing an internal app at ThoughtWorks, and while wondering the same question as millions of other developers, he decided to write a JavaScript library that would be the precursor to IDE -- a library that would record interactions with a page, enabling automatic reruns of tests across a host of browsers. His idea was brilliant. He knew it would resonate with the developer community at-large, and graciously knew he should set his creation free and open source this test creation panacea. JavaScriptTest Runner was released into the wild. Its evolution continued, and one of Jason’s coworkers, Paul Hammant, created a server “that would act like an HTTP proxy, masking the AUT (Application Under Test) under a fictional URL, embedding Selenium Core and the set of tests and delivering them as if they were coming from the same origin. This system became known as the Selenium Remote Control (Selenium RC), or Selenium 1.”1 

As the developer community discovered the utility of both Jason’s and Paul’s efforts, a Google employee, Simon Steward, carried the torch even further, and by 2006, released a more robust version, called WebDriver, that communicated straight to the web browsers via a common wire protocol. Selenium WebDriver was rapidly accepted as the most expedient way for developers to test their code. The juggernauts of SaaS, such as Google and Microsoft, who sport some of the world’s most prolific developers, widely adopted WebDriver. However, it was Sinya Kastani of Japan who saw the need to reduce time required to create test cases in the WebDriver environment, and his resultant commission produced Selenium IDE. For those looking to automate their regression tests, Selenium IDE provided several benefits, including but not limited to its quick setup, intuitive interface, and rapid results. As a Firefox add-on, it only took moments to begin authoring tests; its point and click interface allowed test creation without a deep knowledge of scripting languages; and lastly, the time it took to author tests was vastly quicker than coding manually in Selenium. 

Why Selenium IDE Was not the Solution

With all the above assets, the challenges became readily apparent to developers who sought to use the recorder in complex environments. As web applications have exponentially increased with time, the ability of Selenium IDE to understand the selectors was precipitously ineffectual. Simply stated, the selectors used for identifying elements had to be continuously massaged. A similar problem is manifest when dealing with canvas elements as IDE has no access to the Actions object. Furthermore, a lack of conformity due to IDE being an open sourced project meant the list of commands was immense, creating a headache for new users. Perhaps even more poignant, Selenium IDE was built only for Firefox, and since many developers prefer Chrome, a significant portion of workflow could not be tested in other browsers. While it may seem disingenuous to realistically expect any tool to credibly automate test creation - which is the goal articulated by the Selenium team itself - what is the point of automation if it still requires so much manual input? 

A Recorder is not enough

We let you create tests using interaction recording. That's easy. But our interaction recording is different from others' (like Selenium IDE, RobotCorder, etc.). The difference is that these latter tools focus exclusively on HTML and CSS (which is not a completely reliable guide to what's happening on the rendered page) and on the DOM, which may change dynamically under the control of frameworks, etc., in ways that cause conventional scripts, aimed at selectors, to break. That means tests that are flaky, unreliable, and require constant maintenance. It may even mean that some sites or parts of sites can't be tested automatically at all, unless you write insanely-complicated scripts and/or use expensive manual testers. 

Functionize does things differently:

1. Functionize exploits machine vision to locate and identify selectors, and machine learning to analyze the DOM for meaningful information, rejecting noise and irrelevancies. This means your tests are much harder to break: they won't lose track of a selector because your layout changes a little bit, or because some MVC framework is inserting dynamic object IDs that change from page-load to page-load.
2. Even when tests break, Functionize AI makes astute judgments about what may have gone wrong, and offers you intelligent suggestions for how to fix broken tests -- just point, click, and your test is working again. You can also review logged records of how machine vision perceived the page-render, so quickly figure out edge cases, such as when a button appears offscreen.
3. We also let you create regression tests autonomously, using a simple javascript tag inserted in pages. This can help you achieve great test coverage over very large sites -- thousands of pages -- very quickly and easily.
4. We even support Real User QA, which lets you insert specific tests confirming (for example) that critical page elements (such as legal terms, etc.) are being rendered correctly, and perform these tests in your users’ browsers, each and every time a user interacts with the page, data, or transaction in question -- alerting you in case of error. Thus giving you the ultimate assurance that your page is executing correctly.

Functionize executes tests in the cloud, using autonomous bots, and accessing natively emulated browsers -- all of which scales on demand. You get reliable test results in minutes, on how your site performs with myriad desktop and mobile browsers and devices.

Functionize offers APIs enabling easy integration with your workflow, including premise and hosted CI/CD, packaging, and deployment orchestration frameworks, like Jenkins, CircleCI, Travis, and Spinnaker. 

If you’ve been searching for Selenium alternatives that won’t result in flaky tests, Functionize can get you going quickly and help you author and execute tests extremely rapidly, avoiding the pitfalls of recorder tools that weren’t built to automate test creation in complex environments. 

1 https://dzone.com/articles/in-search-of-the-selenium-ides-successor