Selenium Insight from All-Star SeleniumConf Speakers!

Foreign.

Get ready to discover the most actionable end to end automation advice for some of the smartest testers on the planet. Hey, I'm Joe Calantonio, host of the Test Guild Automation Podcast and my goal is to help you succeed with creating automation awesomeness.

Hey, it's Joe and welcome to another episode of the Test Guild Automation Podcast. And today you're in for a special treat. We have an all star lineup going over Selenium Selenium Conf which is taking place in Chicago March 28th to the 30th. If you haven't already, I highly recommend you Register now@seleniumconf.com and when you register, make sure to use the code TESTGIL2023SE CONF15 to get 15% discount with this code. You actually will find that in the show notes because it's probably hard to remember. Well, once again it's Test Guild 2023 SE conf 15 to get a 50% discount when you register using that code@seleniumconf.com to meet our awesome upcoming speakers in person as well as hang out with me in the on site Test Guild Studio that I'll have set up there. So joining us today we have Karina Pip, who is the QA Lead at Deloitte Digital and also a Selenium Project Leadership Community member. We also have David Burns, Head of Open Source program office at BrowserStack and NightWatchJS project lead, Selenium Project Core Contributor. We also have Naomi, who is the Software Dev Engineer at Amazon. We have Marcus Merrill, Vice President of Technology Strategy for Source Labs. And we have the one and only Simon Stewart, Project Core Contributor and creator of WebDriver. You don't want to miss this episode. Check it out.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Sauce Labs, the cloud based test platform that helps ensure you can develop with confidence at every step from code to deployment. For every framework, browser, OS, mobile device and API, get a free trial. Visit test skill.comSourceLabs and click on the exclusive sponsor section to try it for free today. Check it out.

Hey everyone, welcome back to the Guild.

Hello.

Nice to be back. Thanks for having us.

It's good to have us.

Hello.

Awesome. Awesome. I think you've all been on the show, so it's great to have a reunion of Selenium All Stars. Like I said, I thought to kick it off, it'd be cool to go around the room to get a quick overview of what session you'll be at. You'll be talking about at this year's Selenium Conf I'll give a little teaser so people listening will meet us there in Chicago. So I'll start at the top and work out my way down. So Simon, what's your session going to be on?

I'm going to be at the Committer panel at the end of the second day and I'm going to be watching lots and lots of talks. It's going to be the first Selenium Conf where I am not actually doing like one of the opening keynotes. So that'll be a change and I'm really looking forward to it.

Awesome. Naomi.

So I'm going to be talking about crawlers in general, not only web crawlers, all about them. It sounds like a small topic but it's not. There's a lot to cover about that. I also going to be in the panel but I will be like introducing people and questions which I think they put me there because I usually I'm the one that asks the toughest questions. So it's probably the best way of getting me quiet for that.

As the former moderator of that panel, I can assure you you get to ask your own questions. You just don't tell anyone. That's what you did.

That's a good idea. Take a note on that.

Awesome. How about you Karina?

Yeah, I'm going to discuss a little bit about what's been released in the latest versions of Selenium. What kind of major functionality the developers are working on, some smaller functionality that was introduced while starting with probably after selenium 4 because I think selenium 4 is pretty well known already and you know all kinds of interesting activities that are going on with the PLC and also be part of the panel for the first time ever. I don't know what I'm doing there but I'll try to be supportive. So yeah, it's going to be very interesting.

Awesome. Good. Sounds good. How about you David?

So I'm going to be talking about why browser engines are not equal to desktop engine browsers which are not equal to mobile and kind of the trade offs that come with it when you do that. So kind of just talking about how kind of sometimes real browsers are actually the most important thing because that's where your customers are. So I'll be talking about that and then I'll be on the committers panel at the end.

Nice.

And Marcus definitely be attending David's talk. But also I'm doing a workshop with my friend Manoj Kumar on the Selenium Grid. It's, you know, it's kind of a daunting thing to set up. It's difficult to do, but it's been completely rearchitected, rewritten from the ground up. Selenium for in selenium 4.0. And I couldn't be happier about the progress that's been made on it. I also feel like I should point out that I'm the VP of Technology Strategy for Sauce Labs. I'm running this with the VP of Developer Relations from LambdaTest. So it's completely vendor agnostic. We are going to be talking about the open source part of this and not at all about the, you know, the cloud based offerings around it.

Sounds excellent. So I guess start off with some controversy. I think we talked about this before, Simon. Selenium, I think gets a bad rap because I don't think people understand what it was designed for. To me, I see it as an API that helps you automate browsers. And then people come and they usually build wrappers on top of it to build an automation tool solution. And so they usually compare Selenium to like one of these other tools that do that. And I think it gets kind of muddies the waters. So curious to know a little bit more of what you think Selenium is and maybe a little bit about the WebDriver ecosystem, how people may not know that. You know, when you use Selenium with other pieces that are out there in open source, you get a full enterprise grade solution when done correctly. Am I explaining this correctly? Am I off my rocker? Sure.

You'Re not wrong at all. So like the strap line for Selenium, if you go to the website@selenium.dev is like selenium automates browsers and that's it. When I wrote the WebDriver APIs in the first place, I always envisioned them as sort of like the machine code of browser automation. Almost nobody writes machine code day to day. Everyone writes in a higher level language, right? They write in Python or Ruby or C or Java or whatever it is, but ultimately that ends up being translated down to machine code and then the computer understands how to do that. And I always thought people would take the WebDriver APIs and they would layer on top of it things that were more appropriate for the work they wanted to do that would allow them to do it. So if you go all the way back to that first GTech talk in 2007, I was talking about like building page objects and abstractions over the top and DSLs and like, you wouldn't really be touching the WebDriver APIs. And the thing that I got wrong is that I thought of it as a machine language. And actually lots of people like to use it as their primary mechanism for doing browser automation. And that means that sort of, it's missing a lot of things. Like the newer frameworks come with this sort of batteries included model where it's like, oh, you don't need to worry about where you get the browser from. You don't need to worry about like test framework or whatever it is you're going to use. You just sort of start running it and it's got everything you need. And so that's where sort of the Wider Selenium and WebDriver ecosystem comes in. So from Selenium we developed the W3C WebDriver specification. And that was a sort of collaboration between browser vendors and the Selenium project and a whole bunch of people. It was a sort of multi year effort. I think it took us like seven years in the end to get it all done. But the benefit of that is that now all of the browsers have this sort of baseline level of functionality where you can be assured that you can do certain things with them. And there are multiple different projects that take advantage of that. So there are some, like, I'm sure David will tell you about Nightwatch, which build on top of Webdriver's APIs, Selenium's APIs. And they do more, and they do more of that, batteries included. And there are others like webdriver ao Christian Bremen's project, where they use the underlying protocol. But what that means is, is there's now this sort of broad range of different projects that are all using the sort of same fundamental browser automation mechanisms and they're offering sort of new capabilities and they're able to address sort of different needs that testers or developers may have. Now one of the things I'm really excited about is the next generation of it all, which is the W3C WebDriver bidi bidirectional specification. And the need for that was highlighted by the arrival of tools like puppeteer and playwright in particular, where it's like, hang on a second, being able to introspect into the state of the browser and figure out like what's going on. There is a really important part of the testing process that people want to go through. The problem is that those tools are now tied to one version of one browser, which may not even be a browser that is ever in people's Hands. So Playwright, for example, has a fork of Firefox, and the thing it calls Safari is not Safari. It's a version of WebKit, which they've done various bits on, and they call it Safari, which I was a little bit confusing, but I don't know. There we go. But as the WebDriver bidi specification matures, we will start offering more and more capabilities. And the nice thing is because it's then baked into a W3C standard that will be implemented by multiple browser vendors, and then you're going to be freed from having to pick your framework in order to choose how you automate things. I don't know. Does that answer the question? That was a really long answer.

Yeah, I mean, it does for sure. So, you know, you didn't mention Nightwatch js. So I'm just curious, David, to ask you, using Selenium, is Selenium being used under the covers? I know a lot of people know how these projects work.

It is. So we have a direct dependency on the JavaScript bindings that the Selenium project puts out. But our focus has not been around. It's been simplifying browser automation for people. So how do you go about getting that right? So, you know, we were. We're not necessarily the best at marketing, but, like, we were the first group to bring out, like, component testing. How do you test your react components? Really, really small. Because we thought, oh, let's see what we could do if we could just mount this and see what happens. And it's like, oh, it's in a browser. And now you can go in Firefox, Chrome, Safari and mobile browsers like that, right? Like. And that was our focus. It's like, how could I fix testing without people thinking about what is actually happening under the hood? Because I agree with Simon, right? It's supposed to be like a machine language, you know, if I write Rust and I compile it, it's going to go down to something that, like, people never need to care about, but it does all these cool things and keeps you safe. That's what Nightwatch is supposed to do. Like, you know, we give better error messages because we take what Selenium gives us, fix, tidy them up, and then we give, like, actionable error messages. Like, no such elements. You go, oh, this one's not actually on the page. These are the steps that you should be looking to fix it. So, and go into it, right? Because we can take that information and then kind of make it more developer friendly and then build out from it. Because that's our motto is kind of like let's do things the right way. Right. Like you've got the automation, shouldn't matter what's underneath, how it's doing it, but you've got that automation that's there and you know, it works.

Awesome. Good.

Marcus, I want to point out something also here on this. The ecosystem also, whether we like it or not, includes a whole industry of for profit companies that have adopted the WebDriver tool as it's underneath under the covers mechanism for operating the browser. So there's a famous picture that we have of Simon in 2012 delivering a state of the Union in London where he basically has a graph of the different job opportunities of quick test professional versus selenium. And they converged around 2012 and quick test Professional has since replaced its, you know, DLL whatever mechanism of controlling a browser with the webdriver Open standard. And so have all the other makers of that kind of software out there. So it's not just the open source ecosystem that's depending on this, it's the world that is depending on the this project to continue and build and quickly.

Just lost building on that. Right. We're already seeing Puppeteer have said that they will move to the WebDriver specification as the bits and pieces land in each of the browsers because then Puppeteer can now build off webdriver like we already know this is the direction they're headed. This is all public knowledge. Matthias Bajerns, who's kind of the tech lead at Google, has made this all very public. So it's good to see that people are converging on a standard like Open always wins. Right, so.

So Karina, in your day to day job, is Selenium something you rely on or are there any other tools you like to use with Selenium in the ecosystem that helps you get your job done and make it easier?

Well, my general toolkit, let's say, includes stuff like I have maven projects usually with Java Junit 5 Selenium and I'm using IntelliJ because I like to generate things easy and to reorganize my code easily. So basically this is what I'm doing. I'm kind of using the framework directly without any other frameworks from the ecosystem. But recently as I've kind of discovered a few years ago, the WebDriver weight capabilities and I've started using that in my automation, I realized that it's quite powerful and I'm one of the people, I keep saying this but it's like I'm one of the people who actually can write reliable Selenium tests that I can count on, that I'm really, really proud of. And usually I would have to create my own, let's say, helper Methods that use WebDriver weight in order to fulfill my tasks. And whenever I would move from one project to another, I would have to rebuild the same methods again and again and again. Basically, it's kind of like a set of minimum required methods in order to get everything done properly. So what I did recently was that I actually created a Separate library in GitHub and I started working there and, you know, kind of outsourcing some of these weight methods that I'm generally using because I think they're very useful and I think using that, the approach with those particular methods helps with not having to learn a new language or a new syntax for writing your tests. So I'm all up for, you know, using Selenium directly because I think it's very powerful and I think it has. It offers so many opportunities to do your automation. So I'm. I'm quite a huge fan of it. Even before I joined the project, I was always a huge fan of it because it really helps me out to do my job.

So, yeah, awesome.

And Naomi rounded it out. Any final thoughts on this topic?

Well, you know me, Joe, I automate everything. It's not just my job. For me, Selenium is much more. I use it for many things in my private life. I do a lot of projects with it. I play around a lot. I like playing around with it. I've started doing things with selenium 4 that I didn't know were possible to do with Selenium. Fair enough. I thought that you could only do certain things with certain tools, but not with Selenium. I realized that wasn't the case and I'm super, super dear. Selenium is super, super dear to me right now.

Excellent. Now, I really like stirring the pot here. Someone on LinkedIn posted a comparison of the most popular tools and it started kind of like a firestorm in the comments it has. Obviously it's just based on downloads. I don't know how they come up with the Numbers, but it's GitHub downloads has Playwright, Cypress and Selenium and then people debating whether or not that's accurate doesn't matter. The question, I guess I have is the discussion with the inaccuracies and misleading comparisons. I do this myself just because it makes a title clickbaity like Slam versus Cyprus. It's Just not to say one's better than the other, but it just makes people click on it. But anyway, any thoughts on misleading comparisons between the different tools like Cypress and Playwright? And this just doesn't go with people that love Selenium. I had someone on the Playwright team contact me, upset that I had someone on one of the shows talking about Cypress and they were saying he was misleading. So it goes with all tools complaining about comparisons like that. So anyone have any strong feelings with this or want to kick it off?

I have a. I don't know, a bit of a nuanced take. And I'll let David have a rant. Happy enough to spend some. A little bit of time with Jason Huggins, recently, one of the, you know, the original Selenium developer. And he basically said it's when they stop talking about you that you're no longer relevant. Like, it's okay to be, you know, the one that's put upon. Because if you're endlessly put upon, you're still. You're in the mix. And in our case, we're. We must be at the top of the mix because we're always the thing that people compare against. So I don't know. I guess I just. I don't take it all that seriously. But I do probably agree with what David is about to say.

Go.

So my biggest bugbear about this is that, like, the comparisons, I don't mind people kind of like marketing spin, right? Like that. I'm expecting kind of. I've been in the industry long enough. The problem is, is when I see engineers not able to kind of navigate through that spin. And that's where my bugbear tends to come into it. Because then it's like, oh, this is good enough. And it's like this. It's like, well, it's actually a lot more nuance than that. And so kind of like the whole point of my talk is that, you know, like, we see. And Simon kind of mentioned, you know, Cypress going, oh, we've got Safari support. It's like, no, you have WebKit support, and it's WebKit built on playwright. So it's not even WebKit, right? It's Playwrights WebKit. And so, like, I know when I worked at Mozilla, Playwright people were like, here's a patch. Can you absorb it into the tree? And we're like, looked at it as, like, well, you know, we see what it's going to do, but no, we can't, because it turns off all these security features. And so like when people are using it, like these security features are going to be turned on. So how do you know that your browser is going to be working in that way? And so ultimately it was rejected back then, as far as I'm aware, it's still rejected because those patches still get updated every four weeks in the playwright tree. And we see this more and more, right? And then like the other ones that I kind of generally get annoyed by is like, like WebKit is very close to Safari, right? But it's in the same way that Brave is very close to Edge, right? But there are fundamental differences. A Brave browser is going, even though it's got Chromium under the hood, right? Might render the same way, but the way it does securities, cookies, all of these things, like important things for logging into websites, right? So kind of telemetry and things like that, it blocks them or kind of does different things. And I'm a big fan of being where your users are, right? Like if you're going to test something, be where your users are or at least understand where things are going to be different for, you know, like you can't always have mobile. It's expensive to run your own mobile infrastructure. I get that. Right. And using my employer or kind of Marcus's employer to kind of run those things is also kind of expensive. So you got to have these trade offs at least. Understanding those trade offs is the most important thing. And that's where kind of a lot of the marketing spin just really irks me.

So, Naomi, I know you love to automate everything. I'm sure you have your hands on all these tools. How do you navigate the spin?

I have, I feel like everything has its advantages and inconvenience, right? So it really depends on what you need it for. And the best way to know is not going to a blog or going to a conference even and listening to someone selling the tool that they know better, right? Just go and try it and play with it. I'm just so much fun of, you know, go and have fun and do stuff and then verify what it is better for you and use it and then you'll know what's better for you. Because I think a lot of people are really have a lot of misconception and that's what hurt me, right? When someone goes and say, no, I don't use Cypress or I don't use Selenium, because something that is like not really a reason not to, right? You can actually do this with one or the other. That's not the reason for for you to pick one or the other. Now if you tell things like what David said is like about this is about the security or this is about using this browser. I want actually to use the browser. I don't want to use, like how you say, a demo for it. Right. I want to be able to use the browser as the, the people are going to be using my application, then I will need one or the other. It really depends. You may say, I don't need that. It's enough for me to just demo my browser. I don't need to actually go and use it as a developer. Or I can do it manually or I can set up some, I don't know, some form of devices that I will be using that. So it really, really depends on what you want to do. And it really depends on your preferences as well. Right. A lot of people have issues writing code in one language or another and then that may be a deterrent for them to pick one or the other. So it's really, I don't know, you really need to go case by case and you really need to deep dive in each of them to be able to pick your favorites. Otherwise it wouldn't be fair.

Yeah, for sure. Karina, how do you navigate this? Do you always use Selenium or do you have anyone that says, oh, we have to use Cypress or Playwright or whatever? You have to tell them. Well, hold up.

Yeah, so usually when I start a new project, I would do an analysis regarding what we need to actually test because you know what this huge marketing for certain frameworks tells you, oh, this tool is so great, but it doesn't tell you what it cannot do. So each framework has certain limitations and there are projects where you seriously cannot use one of the frameworks because it doesn't have some of the functionality you actually require in order to automate that project. So this is where you need to be a little bit careful because, you know, if you're just looking at, oh, this is a shiny product, let me use this because it's talked about, it's hyped and so on. You might end up, you know, writing 100 tests and then realizing once you get to a certain, you know, scenario or a certain feature that you need to test that it's not really the proper framework for your automation. So you always need to know beforehand which is the right framework for you. So in order to do that, you might be able to. Or you should start with doing some investigations, doing some proof of concepts to see what is more suitable for your project. Not just going ahead and using one of these frameworks or the other one. And another point I would like to kind of emphasize here. Well, last year I actually read thoroughly the documentation for one of the other frameworks that we discussion here. I don't want to name names, but it was a different framework than Selenium. And I was a little bit shocked by how many times in their official documentation I found references to Selenium. So it wasn't like, hey, this is our tool. This is what we are offering you. This is what we're really good at. It was like, well, as opposed to Selenium, we can do this and that. And I don't think that's fair to market your product this way. And I don't think it's very healthy to do it either. You know, you should focus on your own things. You should bring your tool in front by, you know, showing what great capabilities you have as opposed to, you know, bashing other frameworks and other projects and what they're doing. Because after all, I don't know about other projects, but at least on Selenium you have people who are doing this because they are passionate about their doing. They are doing it out of their own, you know, spare time and stuff like that. They're very committed to what they're doing and they're ultimately here to try to help everybody, you know, do these tasks that we have to do. So at least appreciate that and don't try to be so competitive all the time and so on. You know, I think there's place for everyone. It's just that, you know, everybody has a certain specifics, a set of specifics that they need to accomplish and that's how they should use their tool of choice.

Great advice. Karina Simon, anything? Thoughts? To wrap this up on inaccuracies and misleading comparisons between other tools in Selenium.

I think misleading comparisons is sort of interesting, right? Because quite often people have sort of a large body of Selenium tests and those things are hard to maintain. Like any end to end test is hard to maintain. And so people go like, oh, these are hard to maintain. They're kind of flaky. I'm not sure what to do. And they'll do a spike or an exploration or they'll read an article and they'll do some simple cases with another tool and they'll go like, hang on a second, this appears to be faster, this appears to be more stable. This appears to be like, amazing, let's switch. And then when they get the same number of tests in another tool, they find the same underlying problems because it turns out, like, browser automation is fairly stable these days, but there are so many extra factors that come into play that make it really hard to maintain any test suite using any bit of tooling. Right. And so I think Selenium has this sort of reputation where, like, I worked at one company where they're like, oh, Selenium's rubbish. And so we went, have you tried this WebDriver thing? And they went, no. And so we used WebDriver instead for a little bit. And they were like, this is amazing. And it was like, you realize this is the same tool. And it was because it was sort of like a different perspective and a new way of looking at things. And then what they were able to do when they were writing the webdriver test instead of the Selenium test was they were able to take their learnings and apply the sort of years of experience they had about writing those test suites. And then of course, the end result is going to be something that's more stable and more easy to work with and that is more flexible. Right. And so a lot of these comparisons, people go like, oh yeah, my Selenium tests were like this. And then I moved to this new thing and they don't do an apples to apples comparison. They do a sort of, if I was rewriting this all from scratch, I wouldn't be doing it this way. And so I've now got an opportunity to not write it from scratch. And so now I'm taking that opportunity. You don't need to switch frameworks to do that. And I think any sort of analysis where people are comparing the Selenium way of doing things with any other framework and the way they're doing that is with a Timebox Sprint, is to completely re implement everything in both frameworks as if it were a greenfield project and not try and compare a sort of extant large test suite with a brand new thing where you're able to be fast and nimble. I think sort of an apples to apples comparison, it doesn't happen as often as we'd like. And I think frameworks get a reputation because they've been around for a while and there's a lot of sort of knowledge and experience that people have built up. They're going, oh, you can't do that and you shouldn't do that. And it's like, well, is that true anymore? Which was what Karina was saying, take a look at your actual use cases, figure out what you need to do. And pick the right tool for the job.

Absolutely. I might be off base here as well. I think a lot of times people may not have looked at Selenium 4 with bidi and realize the type of functionality they now get is in line with some of the other tools they may have jump bored to try at the time because Selenium didn't have it. And I don't know if I'm off base with that, but I think right.

Now, with some parity, yeah, absolutely not. Like, there's been so much stuff that's been added, and ironically, some of the other frameworks use Selenium in order to do stuff. So if you want to do remote testing with Playwright, you'll use a Selenium grid in order to do that. And the thing that we tried to do, I think Naomi said it was like, it's a project that tries to work with other projects and to collaborate rather than to be like, you know, we're right, we're the only way of doing things. It's like, no, we're trying to make something that is, you know, always fit for purpose. And that is going to be sort of a pleasant experience for people to use. That's why the WebDriver APIs, when we wrote them in the first place, were designed to lead people in the right direction. So, you know, the original Selenium RC API, you go into your IDE of choice, hit, like, Selenium, hit control space to get the completions, and there'd be, I think there were like 109 different options. It's like, this is a little bit overwhelming. And so we tried to make things a bit more easy to follow. So now when you do, you know, webdriver dot, you get like, a far shorter list. And sort of that's the way we wanted to do things for users. But the reason why we succeeded as a project is because we also took that approach to everyone that we dealt with. Like, we want to collaborate with people and we want to work with people, and we wouldn't be doing a W3C standard if we didn't think, like, hang on a second, this is something that has intrinsic value in and of itself, and by making it available to as many people as possible, we've made, like, the world of testing and automation a little bit more pleasant.

Absolutely. All right. So I thought, you know, I like to keep this at 30 minutes. So my last thing I always ask everyone is a parting piece of actual advice someone could put into place right now to help them with their Selenium Automation efforts. I'll start at the bottom with Marcus and work our way up. So Marcus, actual piece of advice, I.

Think, sort of pursuant to that previous conversation. If you're trying to decide about a framework that you're trying to implement, I think first to me it's always about history and introspection. That may be a boring way to start, but I think you ought to understand the synchronous versus the asynchronous nature of selecting these kinds of tools and some of the fundamental trade offs you're making when you choose what we call a batch framework, which is puppeteer, playwright, Cypress versus a non batch framework which sends its commands every opportunity. One, the batch frameworks are embedding code inside the browser that sort of fundamentally add a Heisenberg uncertainty principle to what's going on. And all those things that Dave mentioned, where Selenium is operating as a user does from outside, in a black box way, in a way that is synchronous now that there are trade offs with making those choices and we're trying to figure out within the project how to mitigate some of those trade offs that you'd have to make to make it better. But I just say, understand fundamentally, what are the biggest risks to your project? What are the trade offs you have to make in order to get there? And then like just real quick example, I was working with a customer recently, they're operating a thing they wanted to Cypress. I know for a fact that their site frequently launches brand new tabs in order to be able to drop an attribution cookie and do all this stuff. Can't do that with Cypress. And they didn't know that. And they were planning a multi, multi month and year effort to convert from Selenium to Cypress. And they didn't know that you couldn't operate multiple tabs of Cypress. So that's it. I mean you need to study, you need to introspect, you need to understand your project and what the capabilities are of the tool that you choose.

Treat your test code as developer code, update your dependencies all the time, set it for maintenance, do all those things that you would do for normal bits of code. Test code is production code, no matter which way you try. Skin it.

Yeah, I think my best advice would be to when you're starting off with learning Selenium, come to the Selenium projects website where we have the official documentation regarding how to use the framework. And if you have any doubts, ask the experts. We do have a Slack channel that you can access. It's the Selenium Slack channel. And if you have any questions there, you know, somebody will always answer you. And we're also just like as a preview, let's say we will be working in the really near future on revamping the documentation a little bit because we want it to be like the go to place for people to learn Selenium from the basics. So stay tuned for that. It's coming hopefully really soon.

I was hoping I was the last one. No, I was just going to say that most of what the other people say already, I think for some people listening it may sound like, oh, that's so difficult, that's tiring. I don't have time for that. I have so many features to complete. I don't have time to go and learning the inside out of a framework. I just want a tool that works right now.

Right?

So my only advice for these people that are thinking of that is like find joy on what you're doing because otherwise you're done for. Find joy and try to find the things that will excite you from what you're doing. That will give you into curiosity. Curiosity will drive you into learning these things. Curiosity will drive you into practicing, trying things, trying projects, thinking. How is this implemented? Can I implement a webdriver? How does that work? Can I extend it? Can I build things on top of that that will give you the bit to keep going and go and do everything that everyone else have said so far?

You know, I love that idea of finding joy. You know, I think it's important if like the thing that you go to work every day is the thing that makes you excited and happy. The piece of actionable advice I would give to people is going to be very old school and very boring, which is remember the test pyramid. Like in the ideal world, you will not have very many Selenium tests, you won't have many end to end tests. And that's because according to the testpyramid, you'll have a large number of small tests of unit tests and a reasonable number of integration tests. And the reason for that is that the reason why we write tests isn't to write tests, it's to get feedback on a change that we've made and to know whether it's safe or not. And we want that feedback as quickly as possible. And when something goes wrong, we want to know where the problem is. So those small tests run really quickly. You can get that feedback super fast. Your end to end tests require more of the system to be working. They are inherently less likely to be stable because they require everything to be working properly and they've got this huge coverage. So when something goes wrong, all you know is that something has gone wrong. You can't pinpoint where it is, and that can take many hours. So my actionable piece of advice is don't write Selenium tests and less facetiously, write as few as you can get away with and try and push that testing further down the test pyramid.

Love it. And my actual piece of advice is, if you haven't already, Register now for seleniumconf@seleniumconf.com and when you register, make sure to use the code TESTGRUILD2023SE conf15 to get 15% discount. With this code you'll actually will find that in the show notes because it's probably hard to remember. Well, once again it's Test Guild 2023 SE conf 15 to get a 50% discount when you register using that code@seleniumconf.com taking a place in Chicago March 20th 30th and meet us all there. Say hello. We'd love to hear your opinions on Selenium as well. So thank you speakers for your awesomeness as always. Thank you so much. Appreciate you all. Thanks again for your automation awesomeness. The links to evident value we covered in this episode head on over to test guild.com a4.3e and if the show has helped you in any way, why not rate it and review it in itunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe and 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. Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguilds.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real world value that can improve the skills or solve a problem for the Guild community. I'd love to hear from you. Head on over to test guild.info and let's make it happen.