Selenium Automation Testing Needs Help to Improve Developer Experience

Selenium’s beloved toolset is often critical for testing expansion and project success. However, Selenium is not a silver bullet regarding speedier test times or improving the developer experience. Like any other tool, Selenium brings along its challenges, like test scalability, slow run times, and parallel testing thresholds.

For developers, slow test times are torture. But by incorporating intelligent tactics to speed and scale up your Selenium testing, you can improve the developer experience and ship higher-quality apps faster. That’s a win-win for everyone.

Selenium 101: Browser Testing Automation

Selenium’s automated testing framework validates web applications across different browsers and platforms. It provides a single interface that allows you to write test scripts in multiple programming languages, including Ruby, Java, NodeJS, PHP, Perl, Python, and C#, among others.

The Selenium set of tools includes three key components:

• Selenium WebDriver - executes test scripts through browser-specific drivers.

• Selenium Grid - executes multiple test scripts on various remote devices simultaneously for parallel testing.

• Selenium IDE - a Chrome and Firefox plugin that logs ‘natural’ interactions in the browser and can also generate code in multiple programming languages. 

Where Selenium Falls Short for Developer Experience

Selenium automates browser testing and is an excellent tool for small teams and companies. However, one of the main issues with Selenium is scalability. As your test suite grows, so do your browser testing variations - the more variables in your testing scenarios and the larger the test suites, the longer the tests take.

While Selenium WebDriver allows for testing on most browsers or operating systems, there are limits on how many tests can run simultaneously and how fast tests can run, based on the amount of hub/node configurations - this causes a scalability issue.

A great example is a company like Netflix, which would need to test on multiple browsers and platforms. Imagine a developer at Netflix creates a code change and then has to wait (and wait) for results to come back because the change is launched on multiple platforms. 

To circumvent that issue, an organization like Netflix may only test during the day on Chrome and then at night on all forums, or if the change is so significant, only run the test weekly – all of this shifts testing right.

While shifting these tests right theoretically speeds up tests, this tactic has a negative impact. Developers are burdened with failed tests later rather than sooner, which creates a testing bottleneck. In terms of building a more positive developer experience, that’s a major roadblock.

But, you can’t eliminate Selenium tests, as they are essential for browser testing. However, the length of tests run on many browsers also hurts developer experience, drags down workflow, and slows ship time.  

To reduce long Selenium test runs and improve developer experience, choosing the right tests to run is the key.

How Parallel Testing Thresholds Limit Developer Experience

Slow test times are kryptonite to developers. One tactic many teams take to avoid slow testing, particularly when it comes to Selenium browser testing, is parallel testing.

If a team needs to run functional tests, testing may feel manageable (if not tedious and mind-numbingly slow) initially; as the test suite naturally grows, so will browser testing variations. 

As the suite grows more extensive and functional tests begin to take up more time, these tests get moved right, run less frequently, or run nightly. And that creates a significant risk for developers: returning to work in the morning, discovering broken functional tests, and then spending time and energy on having to fix the breakage. 

To skip over this common issue, teams often try to break up tests and run them in parallel on different machines or at different times. Parallel testing breaks up tests and runs them in parallel on different machines and instances. Parallel testing aims to reduce test cycle times and developer time spent on testing.

However, this is not a long-term solution. This approach piles on the overhead expenses, as the costs of expensive testing equipment, will always shoot up along with the size of the test suite. The developer time required to manage the intricacies of the parallel testing also balloons upwards.

While running parallel tests can improve test times, this tactic only improves developer experience marginally, as there is always a testing threshold that teams will ultimately reach.

But, there can be a better way. Predictive Test Selection uses machine learning to choose the most critical tests to run for a specific change is the key to slicing test execution time without ever sacrificing quality. 

Related Article: Parallelize your subset runs with the Launchable CLI

How to Shift Left Selenium Browser and Parallel Testing with Launchable

To truly improve developer experience, it’s critical to shift Selenium testing left. Launchable intelligently selects the most crucial Selenium tests to run for every code change, which reduces wait times and empowers developers to ship faster. 

With Launchable’s Predictive Test Selection, developers can run a smaller set of tests daily and only run the more extensive suite 1x a week. Launchable ML learns from historical code changes and test results, which allows developers to always select and run the best Selenium tests for a code change. That means you’re always choosing the right tests to run without the bloated test cycles.

Plus, Launchable allows for subsetting and parallelizing tests. You can do both with Launchable split-subset, which makes it easy to divide a subset into equal chunks to run in parallel.

Enjoy faster feedback, less frustration, and shorter Selenium test cycles for a better developer experience.