#368: End-to-End Web Testing with Playwright Transcript

00:00 How do you test whether your websites are working? Well, Unit tests are great, but for web apps, the number of pieces that have to click together just so are many. You have databases, server codes such as your Flask app, server templates like Jinja, CSS, JavaScript, and even deployment topologies Think, NGINX and UV Acorn.

00:20 Unit test won't cover all of that integration, but Playwright does. Playwright is a modern Pythonic take on testing web apps using code, driving a browser core engine to interact with web apps the way real users and API clients do. I think you'll find a lot to like here, and we have Pandy Knight from Automation Panda here to break it down for us. This is Talk Python to Me episode 369, recorded May 12, 2022.

01:00 Welcome to Talk Python to Me, a weekly podcast on Python. This is your host, Michael Kennedy. Follow me on Twitter, where I'm @mkennedy and keep up with the show and listen to past episodes at talkpython.Fm and follow the show on Twitter via @talkpython. We've started streaming most of our episodes live on YouTube. Subscribe to our YouTube channel over at talk. Python.Fm/YouTube to get notified about upcoming shows and be part of that episode.

01:26 This episode is sponsored by Microsoft. For startups foundershub, check them out at talkpython. Fm/Founders Hub to get early support for your startup, and it's brought to you by Compiler from Red Hat. Listen to an episode of their podcast as they demystify the tech industry over at 'Talkpython.fm/compiler'. Transcripts for this and all of our episodes are brought to you by Assembly AI. Do you need a great automatic speech to text API? Get human level accuracy in just a few lines of code? Visit 'talkpython.fm/assemblyai'.

02:00 Hello, Andy.

02:01 Hey, what's going on?

02:02 What's up? Yeah, it's great to catch up with you.

02:04 Thank you. You as well.

02:05 It's been a while. Actually, the last time that we got to meet up, we were chilling at the 'PyBay'. Right? I believe our places, but what a cool place to meet outside at a food cart conference in San Francisco.

02:18 That was one of the best days of 2021. It was incredible.

02:21 It really was. And I got to tell you, I think more conferences should follow this style. I know if you got a conference in Minnesota in the winter, you probably can't have it outside, but boy, what a neat way to have a conference in the age of COVID, where people felt comfortable.

02:37 Honestly, forget COVID. I would have loved to go to this regardless, but it just works even better because of it.

02:42 Oh, yeah. I'm looking forward to going back this year in September.

02:45 Oh, yeah, it's going to be epic. Okay. Anyway, it was really great to meet you there. And now we're here to talk about testing. It's really what a surprise that you're on the show to Talk testing in Python.

02:58 Who would have thought of all people yeah.

03:01 People may know you from your Automation Panda work and blog and stuff like that.

03:07 Right.

03:07 So let's get started. Your story. How do you get in programming Python? Or maybe just kick it off by talking about Automation Panda may be a good place to set the stage.

03:14 Sure. So I'll start with how Python? Then I'll talk about why Automation Pandas.

03:18 Yeah.

03:18 So I first started programming Python in high school. This was around 2005, I think. Python 2.3 was the new version. I was taking a survey of programming languages. Course, we did a whole bunch of things and the instructor really like Python. So I picked it up a little bit. Isn't too much other than toy around. Then I didn't do anything with Python until about 2015 when I joined a new company in my area called Max Point, and their three languages were Java, C#, and Python.

03:48 I picked up Python and I really loved it again. And that's when I went heads down into it. I've spoken to my first Python conference. It was PyData Carolina 2016, right in my backyard in Durham. IBM was hosting it then I attended Python 2018, and the rest was history.

04:05 I think a lot of people out in the audience listening, many of them have never been to either regional or near international conference PyCon. And so many people I talk to are like, I didn't think I was really good enough to go or experienced enough to go or whatever. And then they say, but I went and it was amazing. And now I feel so much more part of the community. Right. I want to encourage people to. It sounds like you went there and you're like, oh, my gosh, I forgot how cool this place was. This ecosystem was. And I'm in.

04:34 Absolutely. I mean, that's one of the best ways to engage the Python community. Find your local meetup, find your regional conference, or attend the begins.

04:40 Yeah. And unfortunately, there are people who are far away from any of those. But there's really good online meetups. True. Like, I was just on the Py End one and they're doing a hybrid now with the 6ft up folks. And it's like they've got their real in person meet up, but then you can participate and you're up on the screen with the group and whatnot. So there's still ways to do it, even if you feel like, well, I live in small town outside of the small town that has no meetup. Right. I'm the one Python person that I possibly know. So an option.

05:12 Absolutely.

05:13 Okay, so you dive in, get into it, and you've basically been working on it on and off in different aspects for quite a while now.

05:21 Indeed, I consider Python my favorite programming language. Funny fact. Until my current job, from about 2016 through 2021, my main programming language at work was actually C#. And so people would ask me, what do you do with Python at work, I say nothing and they think I'm joking. Like, I'm more of a Python.

05:39 One can dream. But no, it is not true.

05:41 Yes, I do. Java, JavaScript, Python, C#, you name it. Way long ago, I did test automation in Perl for a couple of years. That was fun. Quote unquote.

05:51 I'm going to write a test a regular expression to test the regular expression.

05:54 Oh, my gosh. Oh, my gosh.

05:56 Sorry, I didn't get a flashback.

05:58 It's all right. That's the one gem that's buried in Perl. I would say Perl. Every language has strengths and weaknesses. Pearl strength is regex by far.

06:06 Yes, sure. Anytime I hear people talking about how much they use Perl or love Perl, it's got a really strong text understanding element to what they were doing.

06:17 Nice. We spoke about your jobs and doing the C# thing, and I don't think that that's necessarily that big of. I don't think it's a negative. There's tons of people who they go to work and work in one language, and then they maybe come back and they love Python or vice versa first, and maybe they do Python and they love JavaScript. We could get them help. Just kidding. But I know that for a lot of people, the dream is like, how do I do Python full time? For now, it's a hobby. But how do I like, I'm writing a blog, I'm doing some projects, but I want to do that as my job. Right. So, yeah, you kind of made that transition again, in a sense.

06:50 Yep. Now, being a developer advocate, I play with all the tools at the Sandbox.

06:55 Yeah, that's awesome. So tell us about what you're doing now.

06:58 Sure. So I'm a developer advocate at a company called Appli Tools. Appli Tools focuses on automated visual testing.

07:05 Let's see if I got this right.

07:06 There you go. You got it. Some people think I work at Apple. It's like, no, Appli Tools.

07:10 Appli Tools APPLI Tools. I'll put it in the Show Notes.

07:15 Sure. And so the premise is, a lot of traditional functional testing is either your manual tester banging on a keyboard, looking and clicking through, or if you're doing automation, you're scripting it. Right. With the tool, like Flavorrite or Cypress or Selenium Web Driver or whatever. They're all good tools. But when you're using a browser automation tool, typically you're taking the clicks and the typing, and then you're scraping the Dom on the page to get things like text or attributes of HTML Tags or classes, and you're doing some sort of assertions on those. Right.

07:47 Sometimes as JavaScript like a view front end, and you just get, like, handlebars back with nothing.

07:53 Or you got to do a little bit. So more complicated to scrape it. But still you're just like comparing text. Right?

07:59 Exactly.

08:00 Css. What about visuals? What about JavaScript events being linked up?

08:04 Exactly. And so in that sense, the assertions you're doing are really a bare, minimal validation of the page. The way I like to describe it is most traditional automated scripts will work. If you rip the entire CSS off the page, it would look blood ugly. But your test scripts will go through. So the question is, is that really proving that it works from a human aspect? No. You would expect to make sure that things like your layout are good, that your buttons are there, that your text is aligned, all the colors are bright. And so that's where automated visual testing comes in. That you would take snapshots of different views of your web and mobile apps, whether it's a full page, whether it's a section of the page. And then every time you make changes, you run the test again and they'll take checkpoint comparisons to point out, here's what has changed. And then you, as the tester can decide, is that good or bad?

08:53 Kind of a visual diff, like an image dif and then go from there.

08:57 Yep. It's a little bit shorter than just like a Pixel to Pixel comparison. Right. Because if you had a padding shift by two pixels, all of a sudden everything is blown up. Right? Apple Tools uses.

09:06 Yeah, exactly. If it has the time of day up there and the time it goes from nine to ten, it'll shift everything a little bit.

09:13 Exchanges like that, too. So what Appli Tools does is it uses visual AI to really pick out the things that would be noticeable to a human eye. So if you have a small shift, not a big deal. You can set ignore regions like for certain text areas, like it's the time of day or those kinds of things. So you can really hone these visual assertions that you make. Other thing you can do is because they're taking snapshots of the page. It's like a full Dom capture. It's not just a pixelated screenshot. You can take those snapshots and rerender them on different browser configurations. So, for example, I'm using a Mac. I can test on Chrome and Firefox and Safari and Edge now, but I can't test IE. Well, you could take that snapshot, send it up to the Appli Tools cloud, and then in there you can test it on Ie, there you can test it.

09:57 Or if you're a Windows person, like, good luck with Safari.

10:00 Exactly. Right. That's the other one. If you're on Windows, you want to test Safari, but you can't boom. Appli Tools ultra fast grid is the way to do that. So there's a lot of really cool stuff you can do with visual testing.

10:10 That sounds fun.

10:12 Also, what I do at Appli Tools, I'm a developer advocate, so I stand between company and community. I help the community understand good testing practices. What is visual testing? Help them get the most out of using Appli Tools and also to be in the community to advocate for them. Here are the problems, here are the needs, here are the struggles. How can Appli Tools help me?

10:31 I tell people our tool does this. They say, we don't need that solved. We need the subject. Slightly different things solved.

10:37 And you're like, all right, I'll talk to the team. That kind of stuff, right?

10:40 Yeah, exactly.

10:41 I think the Dev role developer evangelist role is super fun. It sounds like a really neat if you're a little bit extroverted, you like talking to people. You love code.

10:50 It's great.

10:51 So one other thing I do want to mention with the whole Appli Tools developer thing. Appli Tools runs something called Test Automation University, which is a free platform full of online courses about testing, automation and everything on that topic. We got some of the best instructors in the world who have these courses. I've taught three of the Python courses I would recommend. Folks, check it out. Test Automation University, Tau. It's good stuff.

11:17 Awesome. All right. Automation Panda.

11:19 Oh, my goodness. So, yes, I also happen to be called the Automation Panda. That's just me. There's no company or anything. It's just my moniker. It's my Twitter handle. It's my blog. The reason I started the whole Automation Panda thing back in 2016. I got my first position as a senior level engineer, and I thought, wow, this is great. I've achieved my career dream. I'm senior level. People are going to listen to me now. What's next?

11:45 Up until that point, all the work I've ever done have been behind company proprietary walls. Even if that work had not necessarily been proprietary or secret or anything like that. I got sick of rewriting the same thing. Wikipedia pages across multiple teams. So I was like, you know what? Maybe I can do something more public facing. Maybe I can write those Wiki pages on something like a blog that everyone can just Google forward find, especially me, because I don't want to have to repeat the same thing over and over again. And so I was like, okay, I'll start a blog, and I needed a catchy name because you go to whatever website to register your domain. And I'm like, well, Andrew knight.com is not available, and nobody's going to remember Andrew Knight anyway, may come up with something catchy. And I just landed on Automation Panda. Automation for Test Automation Panda because pandas are awesome. There we go.

12:33 Awesome. And pandas hate crashing web apps and desktop apps.

12:38 I think across the different animals throughout the animal Kingdom, they are very finicky about a failed app, I suppose.

12:47 Push or whatever.

12:49 No, that's awesome. And I certainly know you through this, and you've done a lot of general advocacy for testing in the Python space there.

12:57 Yeah, I advocated for good testing before I was a developer advocate.

13:01 That is true.

13:02 Exactly. Well, I mean, I think that that's often how people get into these roles. You think there's probably a lot of people that are thinking like, I would love to have that role. So I'm going to try to apply so I can get that role. And you did a bunch of public speaking and presentations, and I'm sure they saw them. Like, this guy is great. We just need to have him on our team. And I got hired doing in person developer training because I was speaking at user groups and meet ups and conferences and blogging. And they're just like, I see you doing this for free. Would you like a job to do it? I'm like, that sounds awesome. Let's do that.

13:38 Indeed.

13:38 Yeah. It's definitely advice people can take sort of as a path forward.

13:42 Oh, yeah.

13:43 Definitely want to end up where you.

13:44 Are when you generate content that becomes your electronic business card. That's how people get to know you. And so if you do the things you like, the things you like will start coming to you.

13:54 Absolutely. All right. Now how about we talk a little bit of testing?

13:59 Let's do it.

13:59 Yeah. So the kind of testing that we're talking about here is somewhat related, actually, to your current job, Appli Tools. Right.

14:09 I don't know if you're using the same tooling exactly or anything, but it's the similar idea of not just, okay, I've got a stack data structure, and I can push a thing onto it and I can pop it off. And if I put 200 pop it off, it's going to be the second one.

14:24 Okay.

14:25 Our app is working. It's trying to understand more than more of a kind of an integration black box level of testing, would you say?

14:33 Correct.

14:34 I always say there is a big difference between testing code and testing features. Testing code is what we would think of as Whitebox or unit testing, or maybe sometimes subcutaneous testing where you're testing to make sure that the implementation of whatever code you wrote via the function or method or something else is working according to specification. Like, okay, I have a function, an absolute value function. Let me make sure that I have a table of inputs that meet the expected table of outputs. Right. Input ranking output doesn't match. That would be unit testing. And so it's very good for pinpointing things quickly. Unit tests are very fast. It catches problems at their source, but it doesn't test things like, okay, can you actually complete the workflow that this whole big application is designed to do? That's where feature testing comes in. That's where you have to do something.

15:20 Black boxing, unit testing is good when you are focused in on a part of the app. This part is the part that checks whether or not I can access this page, whether or not the user is logged in. So let me try to request it with a user that's not logged in. Let me try to request it with a user. That is, how about now one with who's one's logged in but doesn't have access to some role thing. That is fine. But most applications, as they grow, become Lego pieces that click together, right? If you think about web apps or APIs, I don't even want to think about micro services.

15:56 They become these things like, well, here's the database within schema and constraints, and here's the data layer, and here's my view method. And then these are the routes that are set up based on this view. And here's the static folder for the JavaScript. And then it renders and just hears the HTML. It'd be insanity to try to test those on a unit level and then be sure that, well, I tested the view and then I tested the template and somehow I feel like that's okay because they could get out of sync.

16:25 Exactly.

16:29 This portion of Talk Python to me is brought to you by Microsoft for Startups Founders Hub. Starting a business is hard. By some estimates, over 90% of startups will go out of business in just their first year. With that in mind, Microsoft for Startups set out to understand what startups need to be successful and to create a digital platform to help them overcome those challenges. Microsoft for Startups Founders Hub was born. Founders Hub provides all founders at any stage with free resources to solve their startup challenges. The platform provides technology benefits, access to expert guidance and skilled resources, mentorship and networking connections, and much more. Unlike others in the industry, Microsoft for Startups Founders Hub doesn't require startups to be investor backed or third party validated to participate. Founders Hub is truly open to all, so what do you get if you join them? You speed up your development with free access to GitHub and Microsoft cloud computing resources and the ability to unlock more credits over time to help your startup innovate, Founders Hub is partnering with innovative companies like OpenAI, a global leader in AI research and development, to provide exclusive benefits and discounts through Microsoft for Startups Founders Hub Becoming a founder is no longer about who you know. You'll have access to their mentorship network, giving you a pool of hundreds of mentors across a range of disciplines and areas like idea validation, fundraising, management and coaching, sales and marketing, as well as specific technical stress points. You'll be able to book a one on one meeting with the mentors, many of whom are former founders themselves. Make your idea a reality today with a critical support you'll get from foundershub. To join the program, just visit Talkpython.Fm/ foundershub all one Word the links in your show notes. Thank you to Microsoft for supporting the show.

18:19 Having that full application ready to go and you're testing it as if you were a user is very valuable. It can be painful to set up, it can be painful to think about all the scenarios to do, but it is also incredibly valuable than the results you get from it.

18:33 Yeah, and I made the snarky comment about a Vue or React funding as well, which really requires a little bit more of a test that understands the behavior rather than just creating like a flat test app and requesting the view.

18:47 Exactly.

18:48 You're just going to get back where the binding bits of the JavaScript framework go.

18:52 Exactly.

18:53 You need something like a web browser, right?

18:54 Exactly. Yes. You need to pull up the page, loaded a browser and see what it does. And I know this is the talk Python podcast, and so we love Python. I love Python. But in the web space, it's inevitable unless you use an HTML or something, that Python is going to test JavaScript at some point, right?

19:13 Yeah. They're going to crash together. Definitely in the web space, for sure. Unless you are purely on the API side and probably somehow still it'll warm its way in there. So traditionally this kind of testing has been done by pulling up a browser. It could be several levels. It could be okay, I get my feature implemented and I go click.

19:34 Seems like it's working. Let's push it.

19:37 Let's call that level zero testing. Actually, that's level like point one, because level zero is just make the feature change and push it and then it crashes. Right.

19:47 No test is level zero. But then just above that is I kind of sort of clicked around in the area that I think I might have affected to see that it works. Right. Maybe take it from there. Where do we go from there if we want to be better?

19:58 Well, I would caveat to say maybe it's not necessarily layers of getting better. There is always a place for manual testing. The place for manual testing is what I would consider exploratory testing, because it's still good to have a human go in there and try things and feel the experience.

20:13 Because like we said before, a lot of test automation struggles to handle things like visuals, struggles to handle things like good design, judging design, judging user experience.

20:23 Does it feel laggy or is it.

20:25 Exactly performance issues and stuff? And so people like, they start clicking and typing, it's immediate.

20:34 If anything is laggier than like 24 seconds or something. I forget the name of that threshold. That's categorically bad. What we don't want to do is have the bulk of our testing coverage done. That way we don't want to have the, let's say, like the majority of our functional test cases executed manually because the idea of a test case is a well defined procedure that you step through one through and you do the steps and you make sure it works. That kind of testing is where we might want to quote, unquote level up to something like automation. Right. Where you have these complimentary practices of you have automation do the rote, repetitive but still necessary checks along the way, and then have your humans be creative in exploring and be able to judge the things that a script can't necessarily judge for so. Right.

21:20 That's kind of lovely to leverage continuous integration and tools like that all over the place. And if you don't have these, some basic level of automation, that's more or less inaccessible to you. Right. So let's take an example of I've got a Django CMS that I built and it's opensource, and I want to allow people to send PRS to me to contribute back to this general CMS, like WordPress, but with Django press, I'll just random terms. It probably exists. Who knows? But like, imagine my Django press. I want to allow contributors and they're going to submit stuff. If I don't have something a little bit like the testing you're describing.

21:58 Yes.

21:58 Then every PR, I've got to go download it, try it out and do those things. And as opposed to no, the test didn't pass because you broke this thing first. Fix that, please.

22:07 Exactly. Your automated test suites are your safety net, and they should account for a very high percentage of the coverage that you would want in your testing. Right. The idea is the automated test will do almost all the kinds of things, and then you would just have yourself or someone else go in and just kind of poke around real quick, make sure everything is still good. Let me try to. Okay, good. And then feel good because you spent a little bit of time sanity check, making sure everything is still good from a user experience perspective, while you had the battery of your automated suites and batter the crap out of whatever change to swimming. And it's like, oh, they all passed.

22:46 Yeah, I'm 95% sure we're okay. Now let's go from there.

22:50 Exactly.

22:50 You can also Hone in on the really important things. Right. Like in your CMS thing, maybe there's a reporting section that reports page hits over time. Or if it goes down, that's not great. But if the main page, your main site won't even load, that's worse than the reporting being screwed up.

23:06 Right.

23:06 So you can focus in on those areas and really put the energy where people are going to notice. Consider it fully broken, basically.

23:14 Indeed.

23:15 All right, so the tools of the trade traditionally have been Selenium for this type of thing. Right. And not to bash on Selenium, anyway, it's pretty awesome. But we're going to talk about some sweet new stuff as well. That also works with Python in nice ways.

23:28 Indeed.

23:29 Yeah. So maybe tell people real quick about Selenium.

23:31 Sure.

23:31 We'll talk about playwright and you can compare those.

23:34 Absolutely. So as you said, Michael, Selenium has been the classic browser automation tool. It's been around for gosh well over a decade now. It's hard to believe.

23:46 Almost like two decades. I mean, the very early things that ultimately became the Selenium Project, how Selenium works is that you will have your browser, whether that's Chrome, ie, Firefox, Re, what have you there's the browser, then there is this web driver executable that acts as a proxy between the browser and your test automation code. And then in your test automation code, you have language bindings that will send requests to the slender web driver executable. It used to use a JSON protocol. I think it's funny before they might change things. I don't remember exactly. Basically, you send request to the thing it's proxy goes to the browser, performs whatever thing you wanted. Did you want to click? Did you want to get text? Sends the response back through. And so that's how your automation can control the browser back and forth between browser and your automation through this proxy executable. Selenium is an open source project, so everything is available online. They have multiple language bindings, not just Python, Java, JavaScript, Python, C#, Ruby. I don't know if there are any others, but those would be like the big five. What else? What else? Not only is Selenium open source, but it is also open standards and open governance. Those might be new things or new phrases for some people. So let's go over there real quick. Open source means that the source code for all the implementations for Selena Web driver, as well as the other tools, ID and Grid, which I'll talk about in a moment. Those are all GitHub. You can check out the source, you can look at it, you can fork it, you can make changes, you want to contribute to the main project, you can submit, pull requests. And so that is all open and free open standards. What does that mean? The way Selenium works is it uses the web driver protocol to communicate with browsers. Webdriver as a protocol is a W3C standard. It's something that all major browser vendors are supposed to conform to.

25:45 That was a hard fault battle to get that to be a W3C recommendation. What that means is that hopefully in perpetuity web driver will work with every major browser out there. Right.

25:55 So that there's this Zarodium instead of a chromium in the future. Theoretically.

26:01 Exactly.

26:01 Theoretically, it will come with that, right.

26:03 So that we could use the same protocol. Meaning we could use the same tools to automate the basic browser interactions. So that's open standards, open governance means that Selenium is not controlled by any single party or private entity or single company. The way that the Selenium project is governed is by a consortium of open source contributors and collaborators. I know many of these folks. They span multiple different companies. And so that way it's not like one person can control it. One person can't kill it. And again, everything is open. So it's not like it's a secret little cabal that everybody's scheming together. No, you can go read the meeting notes for the monthly meetings of Selenium. That's Selenium in a nutshell. Most times when people talk about Selenium for browser automation, that means Selenium WebDriver. That's like when you pip install Selenium in Python, you're getting the Selenium web driver package. That's the Python language bindings for the web driver protocol that you can go communicate with the browser. The other two projects, Selenium IDE is basically like a visual builder. So instead of you trying to figure out your expats and everything, you can use Selenium IDE to kind of create a visual builder for your test case steps. And the other project they have is Selenium Grid, which is this scale out solution. So rather than running all the browsers on your local machine for testing, because that will Max out your system resources very quickly. If you parallelized, you can distribute that remotely. So you can have like a cluster of nodes that have ie, some of them have Chrome, some have Safari. So then you make remote requests and do the automation that way. So that's Selenium.

27:38 Okay, very cool. And like you said, it's been around for a while. And then the new one on the block is Playwright.

27:45 And conceptually, people should think of it, like similar to Selenium, I think, as your mental model, I would guess. But then it has some differences and advantages, one of which is it had ten years of experience to build upon. True. Maybe. Tell us about Playwright.

28:02 Sure. So Selenium and Playwright, at their core, the highest level, are both browser automation tools. They go in, they do the clicks, they do the scrapes, they send back the answers. So in that sense, they're similar. And also, I should also just caveat this. The main use case for both Selenium Playwright is test automation. You can use it for any kind of automation, but primarily people use it for testing. Right.

28:25 Okay.

28:25 And I will talk mainly in the domain of testing. I mean, you could use this if you wanted to, I don't know, like refresh a page every hour and scrape it using scrap me or something. But anyway, let's just keep the focus on testing.

28:39 I kind of, like in my history, would have, like, to automate registering for College classes so I could get the 10:00 a.m. classes, not the 730 a.m Calculus class.

28:49 If only right. So Playwright, Selenium both browser automation tools, but the ways in which they go about that are different. Selenium uses that web driver protocol, which kind of operates outside the browser. Playwright uses debug protocols. So basically Chrome Dev tools and Firefox's equivalent and all that. That's what Playwright focuses on. In that case, Playwright can access things about a browser that either Selenium can't or Selenium struggles to. It also makes Playwright run a bit faster than Selenium. One of the big complaints about Selenium based tests is that they are slow. Now, this is due to the nature of them being black box, that you need to have the whole system up. The fact that.

29:37 Right, launch your entire browser and they were going to send messages and then shut it down and then launch it again for the next test. Like that kind of stuff. Right.

29:45 So based on the nature of UI or black box testing, there is sluggishness there. But at the same time, like you just mentioned, the whole browser set up things can be kind of slow. Playwright has some optimizations there that are pretty fast. Another big difference between Playwright and Selenium. Selenium WebDriver is meant to be more of a low level interface. So the interactions that you would do with Selenium are very raw. Like when you do a click, it'll send a click event, and that's it. It doesn't wait for the thing to be received. It doesn't wait for the page to load or do anything magic. It just goes. And so with Selenium, you have to do a lot of explicit waiting for things. Because if you click and you don't wait for the page to reflect and then you proceed to your next interaction, the page might not be ready, the element might not be loaded, and your test will go Kaboo. And then your test suite gets criticized for being, quote, unquote, flaky.

30:43 Yeah, absolutely. Well, this is like what happens in the JavaScript world. It's not the instant the page shows up, it's got to then bring down the JavaScript, then maybe the JavaScript talks to some API, and then it comes back and it binds to some stuff. Like there's a bunch of network steps with built in latency there.

30:59 Exactly. That is the pain point of all types of black box testing. There are inherent race conditions. And when you do test automation in that type of space, then you need to handle appropriate waiting for those rates conditions, or else your test will be flaky. And so in that sense, Selenium WebDriver, the tool does get a bad rap for being flaky when it's not web driver itself. 99% of the time, it's actually the tests written using Web driver that don't have those explicit weights in there.

31:28 But on the other hand, the tool gets used in the way that the tool encourages itself to be used.

31:34 Exactly, yeah, exactly. And so that's exactly where I was going. Because when you see some method driver click, you as the programmer expect it to click and kind of wait for things. Right.

31:47 That's kind of waiting.

31:48 No. And so from experience working on many of these types of test automation projects across all languages and tools, when people are automating their tests, waiting is something that a lot of times they just don't even think of, especially when they're newer to it, whether that is a manual tester who's learning automation for the first time or a developer who's crossing over to automation tests.

32:10 Yeah, well, maybe you're just testing your local Dev machine running on a local Dev server where there's no network latency, and then you go and test against your micro service deployed cloud CDN thing and it just doesn't behave the same. Right, exactly. It could have been working and working, and now it's flaky.

32:29 Exactly. So with that in mind, with selling being that low level kind of tool, I've even talked to her from the swinging people on this. Their thought is Web Driver is meant to be a low level tool that you have to handle all those things yourself, and they even encourage you. You have layers of frameworks on top of Selenium that will handle that kind of stuff for your needs. In fact, at my previous company, I created an open source project in C# called Boa Constrictor, which is a net implementation of the screenplay pattern. To handle those kinds of things like in Java, you have Serenity BDD, which has a layer over it like that. There's something called Selenide.

33:07 There's tons of different little projects out there.

33:09 Sure.

33:09 Compared to Playwrights, PlayWright is not a low level interaction tool. PlayWright is meant to be more modern, more refined, more high level, more do things for you, or the framework is there to help you.

33:24 And so when it comes to waiting, most of the time that you need to do waiting and Playwright. Playwright handles it for you automatically. So for any single interaction where you are interacting with an element, depending on that type of interaction, there is a specific kind of weight automatically built in for that target element to be ready before it does anything with it. Before you go to click, an Element PlayWright is going to be like, well, let's wait about 5 seconds until it appears on the page. And once that thing appears, it's a smart way. So boom, it will dive in and do it then. So you don't have that flakiness that pervades so many older test suites.

34:01 So good. And when your tests are flaky, then you just, it doesn't matter if it fails whatever, it fails sometimes, right? As opposed to, oh no, the test failed. What happened? What went wrong?

34:11 Exactly?

34:11 You want to have a lot of faith and trust that a broken build means something or failed test means something. Yes.

34:20 This portion of Talk Python to Me is brought to you by the Compiler Podcast from Red Hat Just like you, I'm a big fan of Podcasts, and I'm happy to share a new one from a highly respected and open source company. Compiler an original podcast from Red Hat. With more and more of us working from home, it's important to keep our human connection with technology. With Compiler, you'll do just that. The Compiler Podcast unravels industry topics, trends, and things you've always wanted to know about tech through interviews with people who know it best. These conversations include answering big questions like what is technical debt? What are hiring managers actually looking for? And do you have to know how to code to get started in open source? I was a guest on Red Hat's previous podcast, Command Line Heroes and Compiler follows along in that excellent and polished style we came to expect from that show. I just listened to episode twelve of Compiler. How Should We Handle Failure? I really valued their conversation about making space for developers to fail so that they can learn and grow without fear of making mistakes or taking down the production website. It's a conversation we can all relate to, I'm sure. Listen to an episode of Compiler by visiting Talkpython. Fm/compiler. The link is in your Podcast Player's show Notes You can listen to compiler on Apple Podcast, overcast Spotify Podcasts or anywhere you listen to your podcast. And yes, of course you could subscribe by just searching for it in your podcast player, but do so by following Talkpython.fm/compiler so that they know that you came from Talkpython to me. My thanks to the Compiler Podcast for keeping this podcast going strong.

36:00 Before we dive into much to Playwright, just a couple of questions that I think there that are interesting worth covering. Dave Sharp says, I use Selenium for some headless browser tests and automation. Is that possible to play? wright?

36:11 Yes.

36:13 I think the API is probably a little cleaner as well as we'll see in a minute. Then Micah also says, absolutely can recommend Playwright and the Robot Framework side browser library is built on Playwright and Selenium library on top of Selenium faster. It just makes sense.

36:29 Boom.

36:29 Very cool.

36:30 All right.

36:31 Well, we've talked about some of these differences and stuff. Let's maybe just highlight some of the you've introduced it pretty well cross browser because it does Chromium, WebKit and Firefox. And when you say Chromium these days, you're like 96% of all the browsers. Sadly, that covers a lot, right? That's not just testing for Chrome, but that's testing for Edge, Brave, Vivaldi, etcetera, etcetera, cross platform.

36:57 I want to go back to browser because there is an interesting difference here to note between Selenium and Playwright. When you use Selenium, you're testing the full browsers, right? You're testing Google Chrome, you're testing Mozilla Firefox, Microsoft Edge.

37:10 Does it even load up like extensions and stuff like that? Or is it more bare? Is it maybe just below your customization?

37:16 In Selenium, it's the full browser. Whatever you've got, you can do things from a command line to kind of like play with certain things like what user profile, use what user data directly and all that. But essentially, the browser that's installed on your machine is what Selenium web driver would use. But in Playwright, it doesn't use those quote unquote stop browsers. Playwright uses browser projects. So with Playwright, you are not testing Google Chrome. You are literally testing the Chromium project. You're not testing Mozilla Firefox, you're testing the Open Source Firefox project. You're not testing Apple Safari. You're testing the WebKit project. And so when you go to set up and install Playwright, part of the Playwright install command is it will download the latest versions of these browser projects and install them on your machine. And so when Playwright runs, it's running.

38:00 Against those, in a sense, it's a more pure strip down, just the essence of the rendering engine. Javascript.

38:08 Exactly.

38:09 So it is really nice.

38:11 It's an opinionated take. You seem to have a very positive view of that, Michael.

38:15 Yes, I think it's cool. I think it's awesome. I think it's lighter weight. But I would also caveat they may not be usable in all contexts, like if you are a government contractor or you're working at some big bank or some of these older, more legacy shops. They may have very strict requirements on browsers and versions to test it's out there. It exists.

38:36 Maybe one IE 11. And you've got to just run that because they're crummy SharePoint installation from ten years ago, stuff like that, unwilling to upgrade anything but that, log into it or some weird thing like that.

38:48 Right, exactly. So anything like that may be a showstopper for folks who want to use Playwright. My gut tells me that's a very small sliver of the wider industry. But it is something to call.

38:57 Sure. Yeah. So kind of modern web browsers is where you're going to end up.

39:01 Yeah, exactly.

39:02 Sure. Okay. Cross platform Windows, Linux, Mac Plus, CI and Headless. That was sort of touched upon in Dave's question. But maybe discuss this headless versus headed idea of these types of frameworks. Sure.

39:17 So when you're the human and you open up your browser that's headed mode. Why is it called headed mode? Because it's rendering in front of you and it's doing all that fun stuff and you can see it visibly on the screen or in whatever viewport you've got. Headless mode is a way that you can run browsers without having it pop up on the screen and render all that stuff. It'll still do the rendering. It just won't graphically display that to you when you run automated tests, specifically, like in a continuous integration environment, maybe in a GitHub action or something, you want to run Headless mode. Why? Because it uses fewer resources, it's a little bit faster. Nobody is there to look at the screen when it pops up.

39:53 It's got a button. Would you like to upgrade?

39:57 Chrome is great, but you should try Edge. It has this new shopping. No, I don't want that wouldn't happen in the project. That might be more of a selenium thing if you get like, these weird, typically periodic pop ups right from the browser vendors.

40:10 Indeed, when Headless modes first became popular, I want to say about like five years ago, it really became popular with Phantom JS and then Chrome basically came along, did the same thing and kill the JS project. The dude. Just like I'm done use Chrome instead of repo it's like, wow, now all the browsers do this, but it is a recommended practice that when you're running tests for credits, like in CI or something, you do Headless. Also, if you try to do headed mode in certain CI tools or GitHub actions, sometimes you might get these wonking errors, like you couldn't render this thing.

40:42 Yeah. Or maybe like the desktop UI tools and frameworks are not set up to actually show Windows or some weird things. But headed, you might want to see what happened, like if something goes wrong.

40:54 So you would use headed mode when you are developing the test automation on your workbench. Like, I've got Visual Studio code open and I code my test. I want to run it real quick. I want to see it pop up and dance through the page. That's when I would use headed mode. Also interesting thing, I believe by default, Playwright uses headless mode. It's not something that you have to.

41:17 Yeah, I think you're right about that as well. Yeah. If you want a headed mode, you got a headless equals false or headed equals. We'll see it in a second. We'll get to the examples, but you got to opt in. And then you already mentioned the Playwright API is TypeScript JavaScript, Python. Net, and Java. And people were like, I'm not using it. It's not Python. Well, the browsers aren't Python anyway, so it's just like one more layer of who knows how many technologies are in there. But like NumPy has a C layer. This is like a layer to talk to, the thing that does the work. And it's a pretty nice API, as we're going to see in a moment. And then you could also test mobile web, even if you don't have a mobile web thing, because it has native mobile emulation. Yeah, correct.

41:56 That's all viewport size, some of the little options on whatever request it has, just to kind of somewhat emulate what a mobile browser would look like.

42:05 Yeah, very cool. Test, like responsiveness and like a bootstrap menu or something. Auto. Wait, that sounds very promising. It waits for elements to be actionable prior to trying to click them. You already went into the flakiness and racing distance of all that. But that's pretty cool. Web first assertions. What does that mean? That sounds good. Yeah.

42:25 So that kind of goes hand in hand with auto weights. For those of you who are familiar with unit testing in Python, whether that's with unit test or Pytest, no, unit test has its like assert. That library Pi test. You literally just use the assert command in Python. Right? Assert this assert. That all that kind of stuff. When it comes to web testing or really any sort of black box testing, the basic kind of assert statements can be limited again, because a lot of times you have to wait for the value to be ready before you can make a boolean condition of an assertion on it. That's basically what these web first assertions be. In Playwright, there is an expect function. It's in JavaScript, Python, I think it's in the others. But basically you would say something like expect a certain locator to have a certain text value. And what it'll do is wait until said phrase has that text value or wait until this locator appears on the screen. It's a more fluid kind of way of writing assertions. And it also has that built in waiting. And they call a web first because it's the idea that it's putting the emphasis of the condition on the web elements as we would naturally understand them, not trying to shoehorn them into some fixed static boolean conditions.

43:36 Yeah, that's very cool. Okay. And then the last selling point of resiliency here is tracing configure test, retry strategies, capture execution, traces videos and screenshots. So, yeah, we'll see some of the tooling, GUI tools and stuff for this. But, yeah, this sounds really nice.

43:55 If your test fails in CI and you get a video, they click there. And then that gave us 400 or something in JavaScript instead of filling up this form. Like, that sounds pretty nice.

44:06 Oh, yeah.

44:07 And that's a huge advantage that Playwright has over Selenium as well. Like in Selenium, you can capture screenshots along the way, but there's no built in video capture in Playwright. You can not only get screenshots if you want explicitly through the code, implicitly, you slap on the screenshot command line argument. After every single failed test, it will pump out a screenshot. Or you can just be like, give me the whole dank video so I can trace the watch.

44:32 Screenshots are great. Video is lit.

44:35 It's incredible. It's like, oh, my gosh, they did it. They planted the flag. Victory. This is amazing.

44:42 Yeah. Because it's one thing to see it where you have it in headed mode and you can interact it's another when it's on a remote system, maybe a different platform. And you're like, what went wrong with this thing?

44:50 Exactly. Because that's the thing in older times, I kid you not. When people did automation, they would literally push the button on the machine and just like, watch it go, wait for it to finish. And that was automation. No, true automation is it's in some sort of CI system. It runs after every full request, after every commit, or maybe if the Tesla is too big, it runs nightly or a couple of times a week, you are not there to watch it fail. Right. So you need all the evidence you can get. What's the best evidence? Video to see what's happening. And then you dig into logs.

45:22 Yeah. I mean, your only visibility is spinning on CI and then failed.

45:26 Exactly.

45:27 It's really good. I love it. Okay. Stuff about running on modern platforms, but then let's talk the isolation. I think that that's huge. There's two things about sort of authentication and cookies and stuff like that. It's pretty interesting.

45:43 But then just also the isolation. Right. You have this very much in testing, right?

45:48 Yes.

45:49 You don't want to depend on the order of tests for example, at a unit test. And this kind of like don't depend upon the last page you visited for.

45:58 Browser tests and specifically with the isolation and Playwright and the browser context. Here you had mentioned earlier, Michael, about in Selenium, how for every single test, you would have to open a new browser, open a new web driver process, and at the end of it, close it, close it. And the reason you do that, you open and close for every single test is because you want that isolation. You don't want to share web browsers across tests because things can go wrong with Playwright. One of the optimizations is for the entirety of your test suite. You do only have one browser process, so you only have one chromium process at the beginning of everything you started up. And it exists throughout all tests. And you close it, you're like, well, wait, doesn't that violate independence and isolation? What Playwright does is it creates what's called browser contexts out of that. So the slow part is a new.

46:46 Private incognito window, right?

46:49 Exactly.

46:50 It's basically like your own session, your own window, your own user account kind of thing. Browser context are very quick to create and close, so you don't have the 5 seconds to ten second startup and tear down time per test. It's like a split second. So that makes you be able to set up your test a lot faster. And basically it's like an incognito session, so you have access to everything in your scope. But if there are other contexts running at the same time, eg, you're running parallel tests, you can't access anything in the other sandboxes. So it's safe. Right. And it's really a game changer for browser based testing.

47:25 And as you mentioned, it's just like I have a quick count. I think I have six browser tabs and progressive web app open right now. They don't interact.

47:34 Right.

47:34 I mean, that's just how browsers are built. That if I visit laywright Dev and then some other Selenium Dev or whatever, they don't get a spy on each other.

47:43 Right.

47:43 That's just how it works. And so it leverages that say, well, we can do more than one tab at once. Let's go.

47:49 And all of your authentication or browser context. Do you know any of the cookies you have protected by browser context? So you can do a lot of really cool stuff. It's not just you're on a different tab because that comes down to pages off of browser context, which is another thing. But it's full context.

48:07 Yeah, very cool. And then the last sort of selling point that Playwright talks about is that they have a bunch of tooling to go along and help you. Right. We're going to talk about the API next and go see that. And the API is really nice, but sometimes you're like, what is that? Css selector? And I've been writing CSS selectors for many years, so it doesn't bother me. But I remember the beginning of like, what does it mean when there's the arrow versus not the arrow? Or does it need the space or not the space between the dot and the proceeding element?

48:37 I'd rather just go hit me with a stick. I've done more.

48:41 I'm pulling my hair out. So there's some tools like a code Gen, sort of record my interactions and then generate Python or other language. I guess for me, that'll help a lot there, right?

48:52 Yeah.

48:53 Maybe we could talk a bit about really high level, then we could dive into, pull some pictures about it. Sure.

48:58 Yeah. I mean, it's basically that like it fires up a browser, you click through, you say I'm done, and then poops out all the stuff you did in playwright code.

49:05 Yeah, well, you talked about it using the Dev tools. It's very much like the inspect element of the devts'yes. Okay. And then there's an Inspector, a similar, but also kind of like, lets you step through and a trace viewer as well. That's a little bit like the network tab, I guess. Plus snapshots screenshots.

49:23 So Trace viewer is something that you would kind of put on a test for monitoring, and then it poops out all the logs and stuff so you can kind of better phrase through it after the test is done.

49:32 Live Dom snapshots and all that good stuff. Okay, cool. Let's maybe talk through some of the code and how it works. Install easy. Know it, love it, pip install it. But it looks like there's two steps. I pip install Playwright and then I play, wright?

49:46 Yes. So pip install Playwright is what's going to give you the Python Playwright package. I know, that's a lot of peace. What playwright install does is it installs those browser projects, chromium, Firefox, and WebKit.

49:58 Right. Okay, I think you can do playwright install chromium if you want. Just one. Right. Focus in.

50:04 Yes, you can pick the one to install.

50:07 Just install them all. But I have it.

50:10 One other thing that if you're Python, I would strongly recommend you include would be pip install playwright. Pytest, which is the pytest plugin for Playwright. Again, the Playwright package alone is going to be the browser automation tool. The pytest plugin for Playwright is what gives you all the tie ins to Py test. So you can make really nice tests. It gives you the command line options, like that headed option or the video options. It gives you the fixtures for getting the context and the page. So if you're going to be using it for testing, definitely Python Playwright plus Py test. Amazing combo.

50:50 Cool. If you're just doing pure automation, maybe you don't need the Pytest plugins and so on. Cool. Okay, so we've installed it, and then immediately what might catch your eye is when I import, I import playwright.either sync API or Async API. Wait, there's two APIs? How lovely.

51:13 But maybe talk us through what the code keep in mind is audio, but give us a sense of what does it feel like to write code for the Sync API. Then we can see how it changes with Async.

51:21 Sure. So with the Sync API, of course, everything is step by step. It waits before it goes onto the next thing I would say, if you're doing test automation in Python, the Sync API is the way to go. In fact, that py test fixture I mentioned gives you everything sync you would use Async. If you're doing more just rogue automation, you're trying to sign up for your College courses, that would be what you would use, the Async.

51:44 Yeah.

51:44 So in this little snippet, what it's doing here is with Sync API, you're saying browser equals P. Chromium launch. That's opening up a chromium browser instance from Playwright. So that's the full browser. That's the start of the browser process. Then also the next line page equals browser new page. What it's saying there is from that browser instance, create a under the hood. This is not included here. But create a new browser context. And from that browser context, create a new page and give me the page options. All of the interactions in Playwright are going to be going off of that page. If you want to click, if you want to scrape, if you want to send text, all that is going to be on the page. So following that, the next line is the first call we see page dot go to some web address, http playwright Dev. So that would be an example of a browser interaction on the page. That one, because that will load the web page. It's directly off the page. A lot of times you might need to say page locator with your CSS selector XPath. Id to identify an element on the page and then do something on the elements. So you would say pagelocator blah, blah, blah, click pagelocator fill with certain text. I'll be like typing text, right?

53:02 Okay.

53:02 Then the next line we see you.

53:04 Can access like properties like page dot title, right?

53:06 Oh yeah, you can get page title, you can get page URL. I don't know the exact names of everything, but if you're using Visual Studio code and Python typing, then you can get autocomplete and find the whole list. Beautiful.

53:19 Yeah, it's awesome. So another thing it seems like I could do here is we've got P.chromium pit, I presume and so on. I could use a parameterized Py test test and give it the browser chromium.

53:34 Okay, how do I test all the browsers?

53:38 Two things here. Two things here. First of all, what you just recommended as an anti pattern, you never want to use Python parameters to choose browser. Browser is a browser choice. Browser choice is a test control input. That's something that you want the user to specify. I want to target this browser and the way you would want to treat that is to say, okay, I have my whole test suite. Honestly, all Web UI tests should be able to run against any browser. There's no reason why we test on chromium versus Firefox. Or so you would want to say, hey, for this entire test run of these tests that I'm filtering in my suite, target chromium. If you wanted to test on Firefox, you spin up another process and say, okay, run these and target Firefox test control, input, pass in and handle. Now you're probably thinking, okay, so now I can use a Pi test fixture to read an environment variable and pass it in that way. That's what the Playwright Py test plugin does for you.

54:28 Okay, nice. Yeah, we'll get to that in a second.

54:30 Yeah. That's another reason to use a plug in is because literally it's a command line option.

54:35 Projects chromium, projects Firefox. Or you can specify all of them in one, three at a time.

54:40 Got it. Okay, cool. And then there's a similar Async API, but instead of using a with block to create the browser's sort of session up here.

54:51 Right.

54:51 Instead of with sync Playwright SP, we have we create an Async with block to create an Async playwright. And then we await launching the browser or launching the process and then await getting the page. And there's a lot of await on this page. Honestly, this might be the most await dense async thing I've ever seen in my life. Oh, you should see negative. But this is all awaitt, like six lines of await.

55:12 Yeah, no, you're absolutely right. In fact, right before our chat today, I was doing playwright type scripts. And yeah, it's a wait a week all the way down. At least in Python you get to choose.

55:24 Yes, true. Javascript doesn't have the sync options.

55:28 Yeah. But otherwise it's the same. Right, exactly.

55:32 Let me rephrase this. When would you use the Async API?

55:36 I would use the Async API if I'm trying to do some sort of browser automation apart from test automation. Like if I'm trying to write a tool that's trying to log in and register for College course, or I'm trying to scrape numbers off of a dashboard on the website that change every five minutes or something. That will be the case where I would probably write like a PY script and just Puke everything in one file and I would use the Async API. I would use sync API for test automation.

56:04 Got it. Okay. Would it make sense to use the Async API if I was trying to run on all three browsers at once?

56:12 Maybe like an Xdist or something like that? I'm like that would not be the.

56:16 Appropriate way to handle that. What you would do is you would code your test and it would be generic enough to run on any browser. And then when you would launch it using a pytest plugin, you would specify all three browsers to run at the same time, which would basically triple the test. And then you would use pytest xdist3. So it would parallelize that right. So you would write the test as if it's generic and then you would use control options to parallelize and cross browser test.

56:44 Yeah. Probably the Xdist any way? I don't know. You probably know it's probably multiprocess, not threaded anyway, right?

56:51 Yes.

56:52 So it doesn't really matter if it's asynchronous correct. Okay, got it.

56:55 And then here's the example of how you might launch it in headed or not headed mode. You would say like Firefox launch headless equals false. There's another interesting parameter here, Slomo.

57:08 You want your test to be fast. You went on and on about how it was good.

57:11 So when you are developing tests on your local workbench and like I said before, that's when you want to do headed because you want to see it. Playwright is so fast that sometimes you can't track what's going on. I kid you not.

57:22 It's fast. So what you would want to do during your local development or debugging, you might want to inject a slowdown after every interaction. Usually I use like 1000 or 2000 milliseconds just to kind of also I would recommend just like with headless option slow option. You can use the command line. And I would even say that's the preferred way rather than injecting directly to Google. Yeah.

57:45 Probably also just to be nice if you're not testing but you're going around scraping on people's websites, don't hit it as fast as the network will allow.

57:55 Oh, yeah. Because some websites will identify you as a bot and be like, no, I'm rejecting your request. So if you reject the slowmo, you seem more like a human. You'll skirt under the radar. I didn't even think of that. But that's right.

58:07 Yeah. I'm sure that actually it may not be the intent. The intent is to make it human interactable, but it's still it might be necessary.

58:16 Get that College course, get that 10:00 a.m. Class. Don't get banned. Okay.

58:22 I actually did do something like that when I was in College, but using a dial up modem because I had to talk to somebody. But it was glorious. I had the best class schedule year that year. Okay. So another thing you could do is you can record scripts using playwright code Gen and then give it a URL and then it will watch you interact with it and then generate Python to try to mimic those interactions. Right.

58:45 That's pretty awesome. We talked a lot about we'll go back to the Python. There's also a repl mode, which is pretty I mean, I guess that's just saying that you can call Python code in a repl. That's not super interesting.

58:57 If you're coming to Python from another ecosystem, this might be a big deal for you. I think for us we're like, oh yeah, you can do any Python in a rather simple whatever. So somebody come from like the Java world? Oh my gosh, it'll blow their minds, probably.

59:10 Yeah, that's for sure. I guess I'd never really thought about creating an Async repl, but you can create an Async repl using Python async. Io and then you get a repl, but it lets you write await. I've never done that. So I guess I learned something then. Also, it has this interesting way to build itself into a standalone executable, so you don't need Python or anything else to run it using Py installer. But there's some integrated commands. Tell us about this. I'm searching for a way in which this might be relevant to me.

59:41 Well, that would be like the tool that we mentioned versus a test automation suite. Right. If you wanted to build your College course hacker scheduler thing, you could build.

59:51 It and then you can build into.

59:53 It and executable, and then it's a little easier to run. That's all.

59:56 I see. They tell it it takes these command line arguments and it goes in it. Okay, got it. If I want to share it. Sure. By the way, the instructions on the website people are watching, there's a bash, a PowerShell, and a batch version. The bash version doesn't have backslash ends or something. It's a little weird. Just look at the other ones.

01:00:15 All right.

01:00:16 It does have some interesting ideas. You talk about the waiting and it says don't use time sleep. You might be able to get away with async. Io sleep, but don't use time sleep. Use page wait for timeout instead, which is interesting. Apparently the time sleep messes with its internal asynchronous interesting or something, so people be aware of that. All right, let's talk pytest plug in real quick.

01:00:39 Sure.

01:00:40 So we could write a pytest test that takes a page object, which is the browser process is launched, the session is created and a page has been created and then it's handed to you. Exactly.

01:00:53 So like that opening code snippet we just talked about. You don't need to do that. When you're doing py test with the plug in, you basically say I want to use the page fixture, go boom and it gives it to you. So you can immediately jump into things like page, go to page. Locator. Give me this page title page click straight from the test function, which is really nice. It cuts down on all the boys.

01:01:15 Yeah, that's very neat. And then here, right below that, it shows the CLI options headed browser Firefox or multiple browsers and so on.

01:01:28 Very nice, very nice. What else should we talk about? Maybe we could talk text input and stuff just really quick because I feel like that goes a little bit beyond just CSS selectors, like the clicks and the inputs.

01:01:39 Sure.

01:01:40 And so on. Which one you want to talk about inputs. Locators.

01:01:43 There should be a section on selectors if you go down, which I would recommend.

01:01:47 Yeah.

01:01:48 Selectors are the starting point of finding things on the page. You can identify elements on the page from many different kinds of selectors. You can have an ID. Boom. You nail it.

01:02:00 So you can see the page. Right. You can use a CSS selector, you can use an XPath. All those are things that are also selectors available with Selenium, WebDriver and Cyprus. But Playwright has a few other kinds of selectors that it supports. One of the most helpful ones is what they call a text selector. You've got it on the screen here. Yeah.

01:02:18 There you go.

01:02:19 I want the button that says login.

01:02:22 Correct. Exactly. Because I don't care what kind of element it is. I just want the element that has a text that says login that has submit. As long as it's the only one on the page, you're going to get a right that lends to the developer experience. Right. Because you're trying to figure out CSS selectors and expats as a cognitive load. Sometimes you have to do it, but if you don't have to and you can do something easier, it's better for you and for the test case, simple as better than complex. And so here, right? Yeah. Give you the text. Boom. I'll find the element. So that's one of the really cool selectors.

01:02:55 Yeah. That's fantastic. And then you can come in here for input and go and say, I would like to check the check box that has the ID agree. Or that has the text xl. What size of T shirt do you want? I want XL check, that radio button or that check box. That's super cool.

01:03:12 Actually, I should comment that the commands we're seeing here are things like page check, page Uncheck, page fill. That's actually no longer the recommended practice with PlayWright.

01:03:22 You can do it. What do they suggest?

01:03:23 What they suggest is page locator hop in your selector and then whatever the interaction is. So in this case, instead of page.

01:03:31 Check or click agree.

01:03:35 Check. And the reason they recommend that even though it's more verbose, it's ultimately supposed to lead you to a refactoring into things like page objects. Right. Because you are separating the concern of page structure from interaction, whereas when they're together, even though it's more concise, it is readable, you're combining those concerns, it doesn't really matter. You can use both ways.

01:03:58 Sure. Okay. These are nice. All right. So really, basically the takeaway, for example here, I can go and find me the button that says text submit, and then I can do a Hover over it and then click, which I think is interesting because often it doesn't matter. But sometimes if you Hover over a thing, it exposes different Dom elements that when you click on them, they have a different behavior. So you have this really fine grain control.

01:04:21 Indeed.

01:04:22 Got a few.

01:04:24 Sorry, sorry.

01:04:24 I was going to say, like also in that example, we just showed you created the Locator object one time, and then you perform multiple interactions on it, whereas if you had repeated or if you had combined the calls, you would have under the hood duplicated the creation of the same Locator object. So there's a sense of reusability there as well.

01:04:43 That's all. Got it. All right, let's round out our conversation here just quickly with the tools. I think that these are really nice, these visual tools here. The first one I pulled up first is the Playwright Inspector, and it's kind of like I don't even know how to describe it. So it's as if you went through and you did a bunch of CSS stuff, and then playwright wrote asynchronous Python code with the things like page click and whatnot that we discussed, and then you can go and check it out. So this is kind of like a playback understanding type thing, right?

01:05:15 Yeah.

01:05:15 How would you characterize this?

01:05:16 So this is like saying, okay, this is what your code get. Here's more information on it. Very similar to Chrome Dev tools. I will caveat to say I have not used this much myself. This is also kind of new to me, too. Also on top of that, I should say the Playwright team keeps pumping out new, awesome stuff all the time. So older to your butts. They just keep making more awesome, cool stuff. Yeah.

01:05:37 Apparently it has features for debugging, selectors, for stepping through, like one of these playback scripts, see how it goes, and so on.

01:05:44 It's really cool, real time stuff here.

01:05:47 Yeah. This is super neat. Okay, another one, the Trace viewer. This, like I said, looks a little bit like the DevTools of a browser. If you open up the network tab and then Select Show me the response in that view for people who are not seeing this, but you can go to the Playwright Dev site and check it out.

01:06:03 That's a good way to describe it. And it bubbles up, like so many things I think you can say, like, oh, I want to capture the screenshots, I want to capture the video. I want to capture the dobs of the pages. I want the source. And I think it bubbles it up all for you in one artifact. It's like you're testing done. Here you go. Have fun looking at it. So it's the kind of thing where you could let's say you're running this in continuous integration test, fail it, bundles all this stuff up, saves it for you as an artifact, and then you can go look at it later for the ones that fail. So here's all the context of what went wrong, and you can really get in there and figure out what happened.

01:06:38 Yeah, it's fantastic. Has all the actions you click on and it says, what was the action? What was it like before? What was it like after? What did the network do? Yeah, really good. And then test generation because, hey, we don't need to write tests. We'll just tell it to go.

01:06:52 Tell us about this. This is pretty cool, though. This is like fire up the browser, let me interact with it, and then generate a script that I can go from there.

01:07:00 Yeah. Basically it's like a screen recorder. You start the recorder, you navigate through the web page, you do your workflow, you stop the recorder, and then it turns all of the things that you did into a playwright screen. Right.

01:07:11 Instead of recording video, it records asynchronous Python generates. Now this is really cool, and it's super easy. The other thing that's worth noting here is they talk about authenticated state. So if you've got a login and set up some cookies and local storage, even if you've got a JavaScript app that needs to read and write stuff to local storage, you can sort of save and load that from a JavaScript a Json file rather.

01:07:36 Yeah. Because that's another thing, particularly with test automation. How many times you have to log into your app under test username password, token, or whatever.

01:07:45 You can do this with pretty much a browser automation tool. This is how Playwright does it. You're basically caching that authentication so that you can reuse it for different sessions tests. So you don't have to burn that 5 seconds of login every single time.

01:07:59 Sure. If you're not trying to test the login flow. Correct in your way.

01:08:03 Correct.

01:08:03 Yeah. Fantastic. I guess Debugging tools, we can look real quick. I feel like we kind of touched a lot of them. Anything else you want to highlight may be running in debug mode.

01:08:13 It's all good. I would say go read the docs up on it. There's more than we can cover in a 1 hour discussion.

01:08:17 Yeah, well, I think we're down to minutes, not hours. Maybe leave it. There's a bunch of guides about auto waiting, testing, APIs, browser context, JavaScript events. There's a lot of stuff to go in here. Check out even testing video or recording videos. Cool. Fantastic.

01:08:36 And for folks who want to learn more about Playwright, what I can recommend is that I have done a tutorial on Playwright in Python. It's on my GitHub account. It's Playwright Python tutorial. I have given this a Python. I gave this a Python Web conference. I gave this at the Tau Homecoming last year. And in this repository, what it has it has not only example code, but it has full instructions on how you build a test automation project with these tools. And it walks you through in glorious detail all the way. If this is something you want to get hands on with. Yes, there it is. Boom. Give that a try. Check it out, follow the instructions in the tutorial folder, and let me know if you get stuck.

01:09:17 Yeah, this is really great. People can follow along and play with it, right? Do a little duck duck, go basically. Yeah. But take some other public website like Duck Duck, go and figure out how you might go about testing it. Right. Work your way through understanding what you should do to test it and then put that into action with Playwright.

01:09:34 Yeah. All right.

01:09:35 Well, I think that pretty much is the time we've had to talk about this. Anything else you want to quickly touch on before we call it a wrap?

01:09:43 No, I mean, have fun with it. I think Playwright is awesome. I really love what the team is doing. And if anyone ever has questions, all testing, Automation, Playwright Selenium, you name it, it'd be helpful. Twitter Automation Panda.

01:09:56 Right on.

01:09:56 All right.

01:09:57 Now before we get out here, I got to ask the final two questions. If you're going to write some Python code, what editor do you use? Your tutorial may have given it away if you've seen that, but go ahead VS Code.

01:10:09 That's what I've been using recently.

01:10:10 All right, right on. And then notable PyPI package Pivots. Playwright is one of them. But something else you want to recommend, like. Oh, this is cool. People should know about.

01:10:19 I mean, X, typically I would say Py test. Right. But in fact, I just released a package on PyPy during PyCon. I got it dubbed before the final closing keynote.

01:10:29 Oh, nice. Okay.

01:10:30 It's called Screenplay. It is a Pythonic implementation of the Screenplay pattern. It's very minimal right now. It doesn't even have documentation. But if anybody knows about Screenplay pattern and wants to help contribute to that, check out Screenplay.

01:10:42 Hold on.

01:10:42 There it is.

01:10:44 Yeah. All right, I'll put that in. Put that in the show notes. Yeah. Very cool. Thank you.

01:10:48 All right.

01:10:49 Yeah, you bet. Well, it's been really great to have you here. Thanks for sharing all your experience with Playwright. Looks very exciting. It looks like something you just want to play with.

01:10:58 Indeed. Well, thank you for inviting me to Talk. I love to do it.

01:11:01 Yes, you bet. So people are excited to get started. Final call to action. What do you tell if people are.

01:11:05 Excited to get started with Playwright? Check out the website Playwright Dev. Check out my tutorial with the link. And also, if you ever get stuck, you can reach out to me or join the Playwright Slack. The folks in there are very helpful and very quick to respond.

01:11:20 All right, fantastic. Well, thanks again for being here. It's great to chat with you.

01:11:24 Thanks, man. I appreciate it.

01:11:25 Yes, you bet. Bye.

01:11:28 This has been another episode of Talk Python to me. Thank you to our sponsors. Be sure to check out what they're offering. It really helps support the show. Starting a business is hard. Microsoft for Startups Founders Hub provides all founders at any stage with free resources and connections to solve startup challenges. Apply for free today at Talkpython.Fm/foundershub. Listen to an episode of Compiler, an original podcast from Red hat compiler unravels industry topics, trends and things you've always wanted to know about tech through interviews with the people who know it best. Subscribe today by following Talkpython.fm/compiler. Want to level up your Python we have one of the largest catalogs of Python video courses over at Talk Python. Our content ranges from true beginners to deeply advanced topics like memory and async. And best of all, there's not a subscription in site. Check it out for yourself at Training.talkpython.Fm be sure to subscribe to the show, open your favorite podcast app and search for Python. We should be right at the top. You can also find the itunes feed at /itunes, the GooglePlay feed at /play and the Direct rss feed at rss on talkpython FM.

01:12:40 We're live streaming most of our recordings these days. If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython.fm

01:12:50 /Youtube this is your host, Michael Kennedy. Thanks so much for listening, I really appreciate it. Now get out there and write some Python code.