Selenium 4 and What's Next with Simon Stewart

Welcome to the Test Guild Automation Podcast where we all get together to learn more about automation and software testing with your host, Joe Calantonio.

Hey it's Joe and welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Simon Stewart all about Selenium 4 in what's next. If you don't know, Simon lives in London with his family and his dog. He spends his working hours either being paid to hack code or work on Selenium, which he probably does 24. 7. Simon is also the co editor of the W3C WebDriver standard and the WebDriver bidi specs which I just heard of, so I'm gonna ask him about that. But really excited to have Simon on the show. He is the creator of Selenium webdriver so he knows his stuff. You don't wanna miss it, especially if you have anything to do with Selenium and having to upgrade with selenium 4 and want to know what's going on in the future with Selenium. Don't want to miss it. Check it out. And just so you know, I just opened up. You're one of the first few to actually hear this. Automation Guild 2021. It's the fifth annual online conference dedicated 100% to helping you succeed with creating automation awesomeness. We've been doing it since 2017 so it's not something we're doing just because of COVID 19. We are one of the first independent, completely independent online event dedicated 100% to helping you succeed with creating end to end full stack automation awesomeness. It really has more of an indie feel, more of a community. If you haven't experienced it, you definitely want to check it out. We have a really active community in the Slack channel and everyone says it feels like an actual on site conference. We've taken the best of the on site experience and put it into an online format. One of the first to do it. Definitely check it out and if you're listening before November 14th you're going to get the lowest price of the year on these tickets. So definitely head on over to GuildConference.com now and register today. And Simon Stewart is actually going to be presenting at the 2021 event. His session is going to be using Selenium 4 in Anger and as you'll hear in this episode, it may be one of the last times you have a chance to see or hear him at a conference around automation because he is leaving selenium after Selenium 4 is officially released. So Definitely check it out. Head on over to guild conference.com click on the Automation Guild 2021 learn more registration button.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Sauce Labs. Their cloud based test platform helps ensure your favorite mobile apps and websites work flawlessly on every browser, operating system and device. Get a free trial. Visit testguild.com forward/sourcelabs and click on the exclusive sponsor section to try it for free for 14 days. Check it out.

Hey Simon, welcome to the Guild.

Hi there. Thank you very much for inviting me. It's good to see you again.

Awesome to have you on the show. I don't think we've spoken in a few years now. I saw you at a conference a few years ago, I think it was saucecon, and we talked a little. So when we talked originally we really were talking about WebDriver. The.

The W3 standard had just come out and it seems like it's really evolving. I just saw a new thing called webdriver Bidi Spec. And is that new? What is that?

Sure, it's WebDriver bidi, so short for WebDriver bi directional. Because we're not very good at naming things on this project. So there's a good, clear, simple way of doing it. That's what we're going to do.

So that's evolved out of some of the work that's been going on as sort of browser automation has moved forward. And one of the things that is pretty clear is that the original WebDriver spec is designed for a really long. Let me rephrase that. The original WebDriver specific is designed to allow you to have a test running very remotely from the browser. So Source Labs, browser stack, services like that are easy to do, but also you can set up like an internal grid at work. And it turns out that sort of the new generation of browser testing tools that are out there, things like Puppeteer, Cypress Playwright, things like that, they assume that you're running locally and, and what they do is they hook into the browser debugging protocols. And the main difference between the browser debugging protocols and the WebDriver spec, there are many. The major one is that the browser can send events to your test.

So when people say, oh my test using Puppeteer is so much faster, what's actually happening is an event is coming from the browser and they're saving 200 milliseconds, 100 milliseconds. Instead of polling for an update, they get the update coming straight to them. Now the problem with depending on a browser Debugging protocol is obviously these things are designed for debugging browsers. That's what the name is all about.

And so they change with every single release of the browser because there's no requirement for them to be stable APIs that people write code against.

And clearly when you're doing browser automation and you want to support the latest Chrome, the next version of Chrome, the latest Firefox, the next version of Firefox, the latest Edge, da da da, blah blah, you want to be able to take the same APIs and apply them consistently between browsers. What we're doing with WebDriver bidi is we're taking.

The lessons learned from that event driven model where the browser can send events and you can send commands to the browser in a sort of bidirectional way.

And we're implementing that and standardizing it.

So the base that we're going for is something that looks and feels a lot like the Chrome debugging protocol in the same way that when we did WebDriver, the W3C spec, we took the existing WebDriver, the remote JSON protocol from the Selenium project and we tweaked it and we made it nice. We're taking the same kind of approach where we're taking the existing CDP, which is derived largely from WebKit's original implementation. Like all the way back in the missing time, like Chrome used to be based on WebKit and then they forked to become Blink and the Safari folks stayed on WebKit. The underlying debugging protocol is very similar between most of the major browsers. And Mozilla have been putting something similar into Firefox. There's a good basis there that has some commonality. Then what we're doing with the spec method, with the specification. What we're doing with the specification is we are standardizing the modules that people will need, the commands they need, and really clearly defining the behavior of things. Because right now it's completely up in the air. Whichever version of the browser you get, you may or may not get the same behavior. And clearly that's unacceptable when you're writing tests.

Absolutely. So when we spoke a few years back, we were talking about Cypress Ethic and how people, they liked it because it had the Chrome debugging features in it as well. The protocol was this spec part of.

Your thought of, okay, this is probably going to become a thing and if I want to incorporate it into Selenium, we need a better way to do it?

Yeah, I mean, we always try to be sort of Focused on the needs of testers. As we're writing, writing Selenium. Right. The reason why we moved from the original selenium API, the RC API to WebDriver is the selenium RC API was really nice. And that you could type Selenium, hit like the autocomplete button in your IDE and then you would have approximately, slightly exaggerating, you'd have approximately like 9,000 different options. And if you scroll through those and read them, it was a little bit overwhelming. So what we did with webdriver is we moved to a more object oriented model where you hit control space and Instead of having 15,000 things, you instead had, I think we got it down to like five or nine or something like that. It was a really small number when we launched. And then you got a web element out there and that gave you a set of options of things you could do with the web element. So being sort of user focused like that, it's always been something we wanted to do. And one of the things we hear from people is like, ah, you know, it's really hard to do some kinds of testing using Selenium. And I can do that with Puppeteer, I can do that with Cypress because the browser is sending me events and letting me know things. And it's like, well, you know, it would be nice if we could get everything into the current model we have, but we can't. And so you go to where the people are. And so having some support for a bi directional communication mechanism is clearly something that people want, something that people need. And so it's something that we should provide.

Nice.

Does that make sense?

Yeah, it's almost like you're future proofing Selenium as well. You're not adding crud to WebDriver, you're adding another way to get to it almost. So they're not. Does that make sense?

Yeah, the two specifications, we're writing the two specifications so they play nicely together.

Right.

So you can find an element using the current W3C web private spec and you can pass that element into WebDriver bidi. And similarly you could take a reference from WebPrivate bidi and you could use that in standard W3C WebDriver.

So I keep talking about the past, but then I want to go to the future. So W3C, once again, a few years ago was a big deal. It was really hard. You guys really made it happen. That's awesome. Is it everything you thought it would be?

So in my mind I always thought of the W3C spec as a sort of low watermark. At no point, once that spec was in place could browser automation regress behind that point. And I think that's really important because there are so many different browsers and so many different contexts and admittedly there are fewer browser engines than there used to be. Blink appears to be doing very well. The Chromium based browsers are super popular. The Chromium browsers are super popular. But WebKit still there. Gecko is still there. Like Mozilla are still fighting the good fight. And there are smaller engines as well. And so all these people have different browsers and they behave in slightly different ways because they're all forked from different versions.

At different points in time. But you want to ensure consistent behavior. And then there are new form factors appearing, like browsers on televisions, browsers on mobile phones, browsers in cars, I would imagine are coming. At some point that's got to happen. I can't imagine anything more lethal than sitting in a self driving car, browsing the web and not paying attention to the road ahead.

So yeah, like we want. I always thought of that as a sort of low watermark, but clearly it's not enough to be happy with like the lowest possible standard you could get away with. We do want to enhance capabilities and make things nicer.

Nice. So talking about making things nicer, you keep improving on selenium and selenium 4. Is selenium 4 officially released yet? Is it still an alpha?

We are just on the cusp of what should be the last alpha and we have been for a while and progress has been a bit slower than I think anyone would like, if you ask. And primarily the reason for that is that most of the work is done by volunteers and the volunteers are busy with their own lives.

Sadly and very fortunately it depends on how you view it. When we started the project, I think we were all quite junior engineers and now we're sort of 14, 15 years further through our careers and we have a few more responsibilities both at work and in real life. And so finding the time to hack on code is harder than it used to be.

Absolutely. And this is one thing once again we talked about before, about leadership. And what happens is so few core contributors that if someone left and what's the contingency plan? I think in one year in the notes to this, you said some about leadership going forward as one of the talking things, one of the things you want to highlight. What did you mean about leadership going forward? Is there something in the works on how to Make a contingency plan if one of the major contributors no longer has time or to contribute.

Yeah, it's. I mean, I've stood on stage at Selenium Conference. I've said, like, Selenium 4 will be the point where I step away from the project and sort of following the trail that sort of Paul Hammond and Jason Huggins trod before me, where it's like, you know, it's been great, but now somebody else can steer the ship. And sort of, over the past year, year and a half, we've worked really hard on the project to make sure that things that used to be implicit and where it's like, I could make the choice, or a handful of people who are super, well, well, plugged into the project can make a choice. Try and open that up, try and make it clearer, try and make it more accessible. So if you go to the Selenium website, selenium.dev, you'll see that there's a project governance page. We've split the project up into various pieces to make it a bit easier to figure out, like, how can I start contributing? How do I contribute more and what does that mean as we go through. So, as well as contributors, there's a technical leadership Committee, the tlc, and that's made up of the language binding authors and key technical people on the project. And then there's Project Leadership Committee, which has very little to do with actual leadership and everything to do with talking with Software Freedom Conservancy, who are the group that we're under the GS of. And they handle complicated things like legal matters and paying bills when we set up conferences and things like that. So they make the sfc, the Software Freedom Conservancy, allow us to focus on delivering open source. But yeah, all these things that used to be implicit are becoming more explicit. We've written them down and now we can have proper discussions about them. And if you take a look, you'll see that we've got sort of new committees coming through, which is amazing. And we've had existing, committed step up and accept more responsibility as a project moves forward, which I am super pleased to see now.

That's awesome. I think one of the reasons, I don't know if it was Selenium too, when it became a standard, was that the browser makers would take step up and make more contributing to it, because then there's a standard. So does that take the load off having core committers? Because browsers then are responsible for their implementation of the specific.

Yeah.

Having the Browser vendors implement the specification probably saved the project and.

Made everyone's life a lot easier. I say it probably saved the project because we were adding more and more functionality and it was getting increasingly difficult to do that without making modifications to the browsers themselves. Jim Evans did amazing work getting Internet Explorer to what it's meant to do. And we had so much code to try and get Firefox to do what it had to do. And by having the browser vendors take on that work, do the leadership and do the implementation of the W3C spec, what it meant is that we could take a step back and start doing some of the more ancillary things that are absolutely vital to the user experience. So things like the language bindings, sneak peek for what's coming up later. We're reworking Selenium Grid 4 so have it. Not being able to. Not being responsible for doing a browser implementation gave us the capacity to do things like re architect Selenium Grid and various bits and pieces like that. So it allows us to focus more on the ecosystem rather than the browser automation itself.

Awesome. Yeah, that's a good point. You mentioned Selenium Grid. When people think of Selenium, they think of I think three tools. Selenium IDE, Selenium WebDriver and Selenium Grid. So when we talk about Selenium 4, does that apply to all three of those? I don't know what you call them tools or areas.

Yes, absolutely. So Selenium 4 is a nice point for us to sort of reintroduce people to various bits and pieces. So there's the new ide which applitools have poured a huge amount of effort into and made that a web component based. And coming down the track, there's an Electron version as well, which is going to be really nice. So there's a new Selenium idea. There's the new WebDriver bindings where we're bumping the version number because we're taking out the deprecated methods, the things that were less ideal, and we're cleaning up some of the internals of the client side APIs with a focus on maintaining backward compatibility. So you should be able to just drop selenium 4 into your selenium 3 test and it should just work with the caveat that if a method was deprecated, it's probably gone. We try and give people enough of a heads up that, hey look, you should try and do something different here. It's been a year, two years since we did a major release People have had time to look at those deprecation warnings and do something about them. But then there's that. Then there is the new Selenium grid that has been almost completely rebuilt from the ground up to be more suitable for use in the modern world.

Nice. So you're saying when Selenium 4 is officially released, it's an alpha now they'll get a newer Selenium grid. What's new about it? Just, is it behind the scenes? Would people know that it's different if they're just a common user?

Yeah, if you're just running Selenium standalone server, Selenium JART standalone.

You'Ll have the same sort of experience.

Which is kind of nice. But there are things that were bolted on by third party projects that really should be part of the core Selenium project. So the selenium grid 4, for example, you can fire it up and have it use a Docker container out of the box to run your browser instances, which was a feature that Selenium had and some other pieces. And it's like Docker appears to be a staple of the modern web development world, so we should lean into that a little bit. The other thing that we did is you can still run Selenium graders like Hub and the Node, that common model that people have. There are some changes to the config files and stuff like that, but the underlying functionality is the same. But then we've taken it a step further and you can distribute this into a Kubernetes cluster or AWS or GCP or Azure and you can scale a grid to absolutely gargantuan sizes, if that's what you want to do. And if you want to pay the price of running a gargantuan grid on a public infrastructure.

But it's designed to scale sort of horizontally where it can. So we've taken out some of the pieces where it's like, this isn't very efficient, this isn't making the best use of the resources. And now things are designed to sort of scale a bit more easily, which is a lesson, actually that we learned from the solenoid people.

Aerocube are a company and they were talking, it's like, oh yeah, they're making some really good points. And as a Selenium project, we should probably be doing better.

And so that's been a lot of fun.

Awesome. So we talked about taking some stuff away from Selenium 4 deprecation, but I know there's a whole lot of new things as well, like new elements, anything you think people are going to be really excited about that. You baked into selenium 4 that they're going to be like, wow, I didn't know I'm going to be able to do that now.

If I was a user of Selenium, the thing that I would be most looking forward to is what we call the relative locators. So.

I've been to Selenium conference. I think you've probably been to similar conferences where people have whole talks and like, here's how you find an element on a web page and it's very complicated css, a very complicated X path, or stacking up like loads of different locators. And it's like, well, apply some heuristic.

And what you really want to be able to do is like, oh, click on the button that's above this search box or find the image that has the logo and below that there's a login link. People, when they talk about things, they use this very human language where you're going, look, it's above or it's below, it's near this thing.

Relative locators are attempts to encapsulate that in code.

What you can say is find element, and you give it what kind of element you're looking for. So find an input element above here and below here or to the right of this, and it will apply all these filters and then go, okay, this is the element you want. The thing that we need to do is order the returned element by proximity, which we know we need to do.

That's on the list. But it's super nice because now you can suddenly go, okay, fine, I can use a more human way of describing things. That's what I would look forward to probably the most as a user.

Very cool.

I would like to say that we invented that ourselves, but once again, we have taken a leaf out of somebody else's book. In this case, there's a project that started years and years ago called Sahi by Narayan Ranan, and they had relative locators for the longest time. And then you saw new frameworks like Tyco from ThoughtWorks coming through and that has them as well. It's like, you know what? This is an idea whose time has come. And it's probably a good idea for us to put that into Selenium as well, because it's such a useful feature and it's so nice as a user to be able to pick it up.

Absolutely. Even now I'm older, so when I was using qtp, they had this apple, this Type of option where you could do relative locators. So it's really cool. It's coming to Selenium open source. So how much effort does people need to do then? Do they need to make understand this XPath and the CSS of everything they want to be near? Is it just as matters just near the name of this button or the name of this link?

I don't know whether we've implemented near yet, but we will be. We'll have the building blocks to do that once we have proximity sorted out. You need to understand the box model a little bit. So when we say something is to the left of something, what we mean is.

The element you're searching to the left of it means to the very left of that. So the most leftmost edge. So say that's a, I don't know position x50 right. It would be anything under 50 would be considered left if you had something that overlapped a little bit that isn't strictly left off. If you just look at like draw lines across the page. And I think people might find that a bit of a rough edge. So as we go through the betas, I think we're going to find people coming up with perfectly reasonable use cases and we'll be tweaking things to be a bit more appropriate. So hopefully most of the time it'll do exactly what you want to and when it doesn't, it'll be because it's doing exactly what you told it, which is what computers are really good at, but what humans really hate.

Yeah, absolutely. It's all about doing what you tell it to, but you don't know why something failed. I believe there's some new functionality with where was I reading something with exceptions. Are you doing work on exceptions to make it so when it does fail, it's easy to know why.

Not so much exceptions. But baked into the new grid.

We have integrated a framework called OpenTelemetry which allows you to do distributed tracing. And so if I was a sysadmin, the thing that I would be looking forward to with Selenium 4 as well as, hey, look, I can now deploy this on my Kubernetes grid. And that's very exciting would be that when it goes wrong, you can hook into anything that consumes the open tracing outputs and then you can have a look at what's going on in the grid and crack it open and try and figure out like, why is this happening? Tools that support open telemetry, things like Honeycomb and Jaeger and some of those sort of big projects. I think Datadog as well can consume the open telemetry stuff.

So you can just put this into your existing infrastructure for figuring out what the heck is going on and get some insight into what's going on in the grid, which is lovely. Just that level of transparency.

That's cool. That is really cool.

The other thing that we have in the grid is we're working on a new console for it, a new front end, and in order to power that, we've exposed a GraphQL endpoint. And so now you can run a GraphQL query against selenium Grid, either distributed or running on your local machine and you can extract a whole bunch of useful information limited to just the information you actually care about, which is sort of the promise of GraphQL, right?

That is awesome. Wow. I'm getting excited. I haven't been doing automation hands on for a while, but.

I need to put it on my machine again and get into it. So I guess another thing you implement also is we talked a little bit about Chrome debugging protocol. Can you talk a little bit what that means for folks that maybe haven't heard of it before or maybe heard of it with other tools?

Sure. So the Chrome debugging protocol is the protocol that debugging tools use to communicate with Chrome and it is super low level. Think of it like machine code. Nobody would want to use that unless there's no other choice. What you tend to find is that libraries will wrap that and try and add some user facing functionality. So Puppeteer isn't raw CDP is the raw Chrome debugging protocol. It's a layer put on top of that.

Now the problem with Puppeteer is it's JavaScript only and it turns out like JavaScript is wildly popular, but there are still other languages out there. Like the march to dominance hasn't quite finished yet.

So you want to be able to program in lots of different languages. The other thing is that you don't ever really want to have to write code that uses the Chrome debugging protocol directly because it's like writing in machine code. In the same way you don't want to write code that uses the WebDriver protocol directly. That would be incredibly painful. And so what we've done in Selenium 4 is, is we've taken common use cases, we have implemented them on top of the CDP, but with friendly APIs that feel selenium ish. So as an example, if you want to authenticate, you can now register some authentication credentials with Selenium and when you come to a page that says like, would you like to log in? It will then use the credentials you've given it. And it does that at the moment through cdp. Later on it will do it through web replication. Similarly, we can insert network traffic. So if you want to have stubbed backends in your tests, for example, you can just go like, hook my back end here. When the browser makes a request, handle it with this code here in your test itself and have it appear as if the server had sent it to the browser. That's all implemented using CPP because it's an incredibly powerful feature, but we don't expose it that way to users. You just have a thing where it's a really simple API in the Java world, where you have an HTTP request and you return a response and you can do whatever you want in the middle there.

That's what we're doing. We're taking cdp, the Chrome debugging protocol, and we're making it nice and usable for people and isolating people from changes in that. The other thing that we're doing with Selenium, which I haven't seen anyone else do yet, is the alpha that's coming out can support multiple versions of the Chrome debugging protocol at the same time for every language that we support.

So that means you can run a test with the latest Chrome and the previous version of Chrome and the latest Edge and the previous version of Edge and maybe the nightly version of Edge as well, and have your tests work the way you expect them to without needing to download like a completely new browser, a completely new version of the APIs. And that's sort of just one of the ways where we're going like, how will people use this thing? Let's make that nice.

I don't know how people realize how awesome that is. I used to work for a healthcare company and in order to. You couldn't just upgrade or downgrade or FDA came in, you have to run it against the same exact environment that you ran the test in that point in time. So a feature like that would definitely help because it's not going to break anything. You don't have to download anything else. That is awesome. You all have thought of everything this release.

Yeah, we're trying to like. So for a long time we were busy doing the specification and we sort of took our eye off pool a little bit of how people were using it. And then once a spec was done and we had some space, we were then, okay, how will people want to consume this Obviously once I've left the project, I think there's going to be some interesting stuff coming in Selenium 5 because we've done these nice user facing things, but they're all APIs. And the next thing that people want is things like can you download the browser for me and can you download the Chrome driver for me or the Gecko driver or the NSH driver or make sure the Safari driver on my system is configured properly and there are third party libraries that already do all this stuff. And so we tend to point people like, hey, look, if you need this functionality for Java, for example, pick up WebDriver Manager and there are similar tools and then there are other people who are wrapping the WebDriver APIs and they're doing nice things with those. So in the Python world there's Selenium based and obviously in the Ruby world there's Wartier, which does some really nice things to try and make users experience nicer. But I think we've done some nice APIs in 4 and I think the additional functionality would be a really interesting way for whoever is leading Selenium 5 to take the project. But that won't be me, that will be someone else.

I think some people might be getting freaked out now because when I think of Selenium, I think of two people. I think of you and I think of Jim Evans right off the bat. I don't know why, it just pops in my head. Well, obviously Jim Evans, obviously. So I guess when people, when I recommend a tool or a solution, it's usually because of the leadership and how the strength of the community. And obviously you have the community with Selenium, but like are you confident that the leadership after you leave is gonna, is able to handle it? I'm not saying you're a God or anything, but it's just like people want stability and they want to make sure that, that it's not going to be a project that's going to die, then it's still going to have, you know, that kick behind it in the leadership.

Yeah, I am 100% confident in the people that we have in the project.

You know, I'm not going to do what, like do you remember why the lucky stiff from the Ruby community? Who? Maybe you do, maybe you don't.

No.

Okay, so why the lucky stiff was. He did some fantastic things to the Ruby community. He wrote some really nice guides like why the Luck is Stiff's Guide to Rails. I think it was, it was one of the popular things and he did these libraries that people liked, but he always liked to be anonymous. And then somebody figured out who he was and said, I'm going to tell the world who you are. And so he deleted everything. So he deleted all his guides, all his libraries, everything. Right. And clearly like when you're on the Internet, nothing is gone forever. But it took the Ruby community by surprise and it was a bit of an amazing thing to do. I'm not going to do that. I've been telling people for a year and a half behind the scenes since we shipped selenium 3 that my plan is to step away after 4. You see people in the project taking up more responsibility. People like David Burns has been doing a lot of the heavy lifting. Diego Molina as well.

You know, Manoj Kumar has been doing stuff and we're seeing sort of renewed engagement from companies like Source Labs and Browser Stack who are contributing towards the code base. So yeah, I mean, I've been around for a long time but you know, David has been with the project forever, Diego has been with the project forever. And then we've got the sort of renewed energy coming from the investment that the companies are making, which is fantastic to see.

Wow. So.

I can't imagine what are you going to do with all your free time then if you're not messing around with Selenium. Right.

I love build tools. I realize there must be something wrong with me, right? Because it's like.

The first thing is like, oh, what I really want to do is.

You know, a long time ago I used to tell a story that I wrote webdriver by accident and what I wanted to do was I wanted to learn Ruby on Rails. And so I thought I'll write an end to end test as the first thing I do. And the browser automation APIs are rubbish. And it's like, okay, well I tell it, I'm joking obviously. But I tell you what I'll do. I will write my own browser automation API and next week I'll be able to start learning Ruby on rail.

Clearly what's happened is I've got far enough along and it turns out building software is awful. Before I can run my end to end tests, I now need to have a decent build tool and that's what I'll focus on.

Awesome. Okay, Simon, before we go, is there one piece of actual advice you can give to someone to help them with the selenium 4 and beyond automation testing efforts and what's going to be the best way to find and contact you going forward?

The best piece of advice I can give about automation efforts is to remember the test pyramid. If you have a lot of small tests and a few integration tests, and maybe like one or two selenium tests, end to end tests, you're doing it right. If you have thousands of end to end tests, possibly using Selenium and five unit tests, small tests, then you're in a whole world of pain.

And it's been true since before I started Selenium. And it's true to this day.

If you want to find me, probably the best way is.

HS96C on Twitter. That isn't my password by the way, that's actually the Twitter handle.

Thank you Simon for your Selenium Automation awesomeness. And if not for you, probably everyone listening to this would not have a job, or at least not have an awesome job using something as cool as Selenium. So thank you so much for all you have done for the community. The links to everything that we covered in this episode. Head on over to testguild.com a327.

And while you're there, make sure to click on the Try for Free Today link under the Exclusive Sponsor section to learn all about Sauce Labs awesome products and services. And once again, you don't want to miss out on the early bird pricing for Automation Guild 2021. Our goal is you learn a tip, tool, technique or best practice that's going to help accelerate your new or existing automation efforts in the new year. That's why we always do it in January or February. You don't want to miss it. Head on over to guildconferences.com register today. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe. My mission is to help you succeed with creating end to end full stack Automation Awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Automation Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.