Webinar: Building Selenium Automation Framework [Voices of Community]

Even though several frameworks are available in the market for automation testing, Selenium is one of the most renowned open-source frameworks used by experts due to its numerous features and benefits.

Selenium framework allows you to automate your testing of web applications or websites across different browsers and operating systems. Selenium provides compatibility with multiple programming languages, allowing you to write automated tests in any language you’re comfortable with.

In addition, Selenium automation testing is cost-effective because its tools are free to use for frequent regression testing and unlimited iterations of test case execution. It also supports Agile-based development methodologies, allowing you to prepare custom bug reports. If you’re looking to improve your Selenium interview skills, check out our curated list of Selenium interview questions and answers.

We’re sure you would have many questions about how Selenium came into existence, the lessons learned along the way, some the hard way, some by accident, and some by luck, and who’s better to talk about it than the man himself, Simon Stewart.

In our recent episode of Voices of Community, we had a special guest Simon Stewart, Creator of Selenium WebDriver, teamed up with Manoj Kumar, VP of Developer Relations at LambdaTest, to discuss the history of the Selenium project, the valuable lessons learned, and its future.

If you missed the power-packed webinar, let us look at the event’s major highlights.

About the Webinar

The webinar starts with Simon discussing the origin of Selenium and the lessons he learned by working with open source.

Code Lives Forever

Simon explains that, as coders, intuitively, we all know that even if it takes us an incredibly long time to write some code, it’s likely to stay in our sorcery pose and be active for a significantly longer time. He adds that there are lines of code in Selenium that have remained unchanged since Selenium RC was first released those years ago.

Simon explains that he has contributed patches here and there for a while to various projects. Still, the thing that became the focus of his open-source efforts was WebDriver and then Selenium. He further adds why you should never trust an engineer’s estimate and explains in his case that his estimate was wildly incorrect to take WebDriver to a decent state. As per him, he estimated a few months that ended up being over 15 years.

Just Because It Looks Easy, Doesn’t Mean It’s Easy

Simon states an example of something looking easy but is complicated: the simple matter of handling alerts in Selenium. He adds that while using the original Selenium RC, when you see this alert, you would say perform this action or how you will handle it. This happened because they needed to override some internal functions in a window, such as alert and prompt.

Another example he gave was that with the Webdriver, he wanted a reactive API. As a result, when you do something, the browser shows an alert, and you respond to that alert which he thought would be easy to do.

There Is Power In Cooperation

In this lesson, Simon explains how working together in a team can take you far to becoming successful. With the help of his team of talented programmers on the journey of creating Selenium, Simon then emphasizes that writing a spec is both necessary and incredibly demanding. He explains how the Opera browser opened the door and turned the WebDriver API into a W3C spec astoundingly fast.

He mentions that the idea of working with the W3C was a stroke of genius. Writing a browser automation framework that binds tightly to a browser in the same way that WebDriver does is a massive technical challenge they faced in Firefox’s case.

Code Is Plastic and Entirely Disposable

Simon suggests you can shape and change the code as much as you’d like. He adds that the trick is to be unafraid of deleting the code. You can try out an idea and explore different ways of solving a problem, and each time, you can keep learning and throw away the code.

He explains the first time we solve the problem, it’s very unlikely you’ve solved it most reliably or elegantly. Your solution likely has bits left over from wrong turns and dead ends as the digital equivalent of your appendix. The important thing left over from these explorations is the knowledge you have of the problem and what the best solution may look like. The nice thing is once the code is written, you can always change it again, and that’s what he meant by code being plastic and never set in stone.

Favor Simplicity, But Don’t Shy Away From Complexity

Simon explains this lesson with an example. He states that for his team to be able to fix a bug in one place and know that it works for the Selenium Grid no matter how it’s deployed, they arrived at a solution that is hard to describe as simple, yet there’s not much that’s not necessary for it. Accidental complexity, on the other hand, represents the problems and challenges engineers and software developers introduce to their software by accident.

Origin of WebDriver

Simon then shares the origin story of WebDriver. He then talks about his primary focus with the WebDriver while mentioning in the first public WebDriver talk at GTAC in 2007, which was the ability to do bi-directional communication. He adds that a lot happens inside a browser, and being notified of a change of state within it can be incredibly useful. There’s a way to get hold of this information that’s already available. Simply hook into the debugger for the browser, and all the information you need is there.

Use Selenium on LambdaTest

Simon explains how LambdaTest can help deal with debugging protocols never designed for browser automation. He adds that platforms like LambdaTest allow your test to run locally, accessing necessary resources on your machine or corporate network while still allowing you to use a browser remotely. Every message or command to the browser has to traverse from your machine across the Internet into LambdaTest’s online Selenium Grid to the browser and then potentially back again.

The All-New WebDriver BiDi!

Moving forward, Simon talks about WebDriver BiDi. He explains that as a starting point, his team is taking the Chrome debugging protocol, the CDP that many tools depend on, and we’re working hard to regularize it and make it less chatty. Simon adds that creating an expressive bi-directional communication protocol and specifying how it should work has a high level of necessary complexity.

The Future of Selenium

Simon insists that the Selenium team is currently working together on a new tool called Selenium Manager to handle the complexity of juggling the various browsers and driver versions. As per him, the nice thing about this is that rather than having it as a standalone tool you’ll need to handle yourself, the Selenium team will be shipping Selenium Manager as a core part of Selenium itself.

According to Simon, the vision is that you’ll add a dependency to Selenium on your project, and behind the scenes, you will download the browser and the driver for you. He claims that this will make a whole class of problems go away.

Simon’s final thought as he considers the future of Selenium is that it is interesting to note how the project is being run now. One of the things he saw in the last few years of his time as a Project Lead was setting up the project leadership committee and the technical leadership committee. According to him, these groups are deeply connected to the Selenium project and community and are looking for ways to improve the project, which is already paying off.

Simon then ends this insightful session by summarizing the lessons he had learned and shared while building Selenium.

Q&A Session

Before wrapping up, John answered several questions the viewers raised. Here are some of the insightful questions from the session:

1. Are there any best practices you recommend to speed up my Selenium testing integrations?

One of the things I used to do while I was at Google is I’d walk around. I would tell teams to stop using Selenium, which continued writing integration tests like sub-writing large tests like we have the test pyramid, which I know is old and boring and has been discussed endlessly. But the idea of having many end-to-end tests and a smaller number of unit tests leads to slower and flakier test suites. The best advice I can give is when you feel the urge to create a new end-to-end test, think if you need to create it, or could you hook it into an existing smoke test, or is there anything you can do to make it a smaller test?

You can also use platforms such as LambdaTest and run your tests in parallel and let somebody else handle running all the browsers because the heavy thing in that test will be your browser, and if you can run 100 tests in parallel, then you’ll be able to get things back faster.

2. Sorry to go back down the emotional lane. Was there any time when you faced self-doubt about the project and felt like giving up on it? If so, how do you get past this?

Some people at work were telling me I was mad because writing the way that the WebDriver does, where you’re in the bowels of the browser, and you’re tightly integrated, you need to know a lot about every browser, and scaling that out is a complete errand.

There will be like a little corner of a problem which is fascinating, so I’ll pick away at that little corner, and then over time, the sort of energy and the enthusiasm comes back.

3. What is the plan for simplifying dev tools API for WebDriver users?

So the original WebDriver bindings that Facebook did in PHP for Selenium were the wire protocol, which is a terrible way to try and control the browser. You would want something a bit higher to express yourself clearly.

Similarly, many people are using raw CVP, the wire protocol, to try and do things, which is incredibly painful. We did this in Selenium to see some of this emerging in Selenium 4 as we focused on the use cases people are trying to solve.

Hope You Enjoyed The Webinar!

We hope you liked the webinar. In case you missed it, please find the webinar recording above. Make sure to share this webinar with anyone who wants to learn more about the origin of Selenium and WebDriver. Stay tuned for more exciting LambdaTest Webinars. You can also subscribe to our newsletter Coding Jag to stay on top of everything testing and more!

That’s all for now, happy testing!