Although several frameworks are available in the market for automation testing, Selenium is one of the most popular open source frameworks used by experts due to its many features and benefits.
Selenium Framework allows you to automate the testing of web applications or websites using different browsers and operating systems. Selenium provides compatibility with many programming languages, allowing you to write automated tests in any language you’re comfortable with.
Additionally, Selenium automation testing is cost-effective as its tools can be used for free 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.
We’re sure you’ll have lots of questions about how Selenium came about, the lessons learned along the way, some the hard way, some by accident, some by luck, and who better to talk about it than Simon himself. Stuart:
In our latest episode of Community Voices, we had special guest Simon Stewart, creator of Selenium WebDriver, join LambdaTest’s VP of Developer Relations, Manoj Kumar, to discuss the history of the Selenium project, valuable lessons learned, and its future.
If you missed the powerful webinar, let’s take a look at the highlights of the event.
About the Webinar
The webinar begins with Simon discussing the origins of Selenium and the lessons he’s learned working with open source.
Code lives forever
Simon explains that as coders, intuitively, we all know that even if it takes us a very long time to write some code, it’s likely to stay in our wizardry 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 all those years ago.
Simon explains that he has been contributing patches here and there to various projects for a while. However, the thing that became the focus of his open source efforts was WebDriver and then Selenium. He then adds why you should never trust an engineer’s estimate, and explains that in his case, his estimate was grossly incorrect in getting WebDriver up to scratch. According to him, he estimated several months that ended more than 15 years ago.
Just because it looks easy doesn’t mean it is
Simon mentions an example where something looks easy but is complicated. A simple task of handling notifications in selenium. He adds that when using the original Selenium RC, when you see this alert, you’ll tell it to do this action or how you’re going to handle it. This happened because they had to override some internal functions of the window, such as alert and prompt.
Another example he gave was that with 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 it thought would be easy to do.
There is strength in cooperation
In this lesson, Simon explains how working together as a team can take you far towards success. With the help of his talented team of developers on the way to building Selenium, Simon further emphasizes that writing a specification is both necessary and incredibly demanding. He explains how the Opera browser opened the door and converted the WebDriver API to the W3C specification with astonishing speed.
He notes that the idea of working with W3C was genius. Writing a browser automation framework that binds tightly to the browser the way WebDriver does is a huge technical challenge that they faced with Firefox.
The code is plastic and completely disposable
Simon suggests that you can design and change the code as much as you like. The trick, he adds, is to not be afraid to delete the code. You can try out an idea and explore different ways to solve a problem, and each time you can keep learning and discard the code.
He explains that the first time we solve a problem, it’s very unlikely that you’ve solved it in the most reliable or elegant way. Your solution probably has bits left over from wrong turns and dead ends as the digital equivalent of your application. The important thing left from these studies is your knowledge of the problem and the best solution. The nice thing is that 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.
Embrace simplicity, but don’t shy away from complexity
Simon explains this lesson with an example. He notes that so his team can fix the bug in one place and know it works for Selenium Grid no matter how it’s deployed, they’ve come up with a solution that’s hard to describe as simple, but still there isn’t much that isn’t. necessary for that. Incidental complexity, on the other hand, represents the problems and challenges that engineers and software developers accidentally introduce into their software.
The origin of WebDriver
Simon then shares WebDriver’s origin story. He then talks about his main focus with WebDriver, noting WebDriver’s first public talk at GTAC in 2007, which was the ability to do two-way communication. There’s a lot going on inside the browser, he adds, and being notified of state changes inside it can be incredibly useful. There is a way to obtain this information that is already available. Just turn on the browser debugger and all the information you need is there.
Use Selenium in LambdaTest
Simon explains how LambdaTest can help handle debugging protocols that were never intended for browser automation. He adds that platforms like LambdaTest allow you to run your test locally by accessing the 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 travel from your machine over the Internet to LambdaTest’s online Selenium Grid to the browser, and then possibly back again.
Brand new WebDriver BiDi!
Moving on, Simon talks about WebDriver BiDi. He explains that as a starting point, his team adopts Chrome’s debugging protocol, CDP, which many tools depend on, and we’re working hard to standardize it and make it less chatty. Simon adds that creating an expressive two-way communication protocol and specifying how it should work has a high level of necessary complexity.
The Future of Selenium
Simon claims that the Selenium team is currently working on a new tool called Selenium Manager to handle the complexities associated with different browsers and driver versions. The good thing about this, he said, is that instead of having it as a standalone tool that you have to deal with yourself, the Selenium team will ship Selenium Manager as part of Selenium itself.
According to Simon, the vision is that you’ll add a dependency to Selenium in your project, and behind the scenes you’ll download the browser and driver for you. He claims it will eliminate a whole host of problems.
Simon’s final point as he looks at the future of Selenium is that it’s interesting to note how the project is currently being implemented. One of the things he saw in his last few years as Project Manager was the creation of a project steering committee and a technical steering committee. According to him, these groups are deeply connected to the “Selenium” project and community and are looking for ways to improve the program, which is already producing results.
Simon then concludes this insightful session by summarizing the lessons he learned and shared while building Selenium.
Question and answer session
Before wrapping up, John answered a few questions raised by viewers. Here are some insightful questions from the session.
1. Are there any best practices you recommend to speed up my selenium test integrations?
One of the things I did when I was at Google was walk around. I would tell teams to stop using Selenium, which continued to write integration tests, like writing large tests like the test stack we have, which I know is old and boring and discussed endlessly. But the idea of having many end-to-end tests and having a smaller number of unit tests leads to slower and lighter test suites. The best advice I can give is when you feel like creating a new smoke test, think about whether you need to create one, or if you can connect it to an existing smoke test, or if there is something that can to make it a smaller test.
You can also use platforms like LambdaTest and run your tests in parallel and let someone else handle all the browsers, because the heaviest part of that test will be your browser, and if you can run 100 tests in parallel, you can do more retrieve items quickly.
2. Sorry for going back on the emotional trail. Was there a time when you faced self-doubt about a project and wanted to give it up? If so, how do you get through this?
Some people at work told me I was crazy because writing the way WebDriver does, where you’re deep in the browser and tightly integrated, you have to know a lot about each browser and extend that. going out is a complete assignment.
There’s going to be a little corner of the problem that’s fascinating, so I’ll take that little corner, and then over time the energy and enthusiasm will come back.
3. What is the developer tools API simplification program for WebDriver users?
So the original WebDriver bindings that Facebook did for Selenium in PHP was the string protocol, which is a terrible way to control the browser. You’ll want something a little taller to make a statement.
Likewise, many people use raw CVP, the over-the-wire protocol, to try to do things, which is incredibly painful. We did this in Selenium to see some of it show up in Selenium 4 because we focused on the use cases that people were trying to solve.
We hope you enjoyed the webinar.
We hope you enjoyed the webinar. If you missed it, please find the recording of the webinar above. Be sure to share this webinar with anyone who wants to learn more about the origins of Selenium and WebDriver. Stay tuned for more interesting LambdaTest webinars. You can also subscribe to our newsletter, Coding Jag, to keep up with everything testing and more.
That’s it for now, happy testing!