End-to-End Web Testing with Playwright

00:00 How do you test whether your websites are working well?

00:02 Unit tests are great, but for web apps, the number of pieces that have to click together just so are many.

00:09 You have databases, server code, such as your Flask app, server templates like Jinja, CSS, JavaScript, and even deployment topologies.

00:18 Think Nginx and UVicorn.

00:20 Unit tests won't cover all of that integration, but Playwright does.

00:24 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.

00:34 I think you'll find a lot to like here.

00:36 And we have Pandy Knight from Automation Panda here to break it down for us.

00:41 This is Talk Python to Me, episode 369, recorded May 12, 2022.

00:47 Welcome to Talk Python to Me, a weekly podcast on Python.

01:03 This is your host, Michael Kennedy.

01:05 Follow me on Twitter where I'm @mkennedy and keep up with the show and listen to past episodes at talkpython.fm.

01:11 And follow the show on Twitter via at Talk Python.

01:14 We've started streaming most of our episodes live on YouTube.

01:18 Subscribe to our YouTube channel over at talkpython.fm/youtube to get notified about upcoming shows and be part of that episode.

01:25 This episode is sponsored by Microsoft for Startups Founders Hub.

01:30 Check them out at talkpython.fm/founders hub to get early support for your startup.

01:35 And it's brought to you by Compiler from Red Hat.

01:39 Listen to an episode of their podcast as they demystify the tech industry over at talkpython.fm/compiler.

01:47 Transcripts for this and all of our episodes are brought to you by Assembly AI.

01:51 Do you need a great automatic speech to text API?

01:54 Get human level accuracy in just a few lines of code.

01:56 Visit talkpython.fm/assemblyai.

02:00 Hello, Andy.

02:01 Hey, what's going on?

02:02 What's up?

02:02 Man, it's great to catch up with you.

02:04 Oh, thank you.

02:04 You as well.

02:05 It's been a while.

02:06 Actually, the last time that we got to meet up, we were chilling at the Pi Bay, right?

02:11 I believe so.

02:12 Pretty far from both of our places.

02:13 But what a cool place to meet.

02:14 Outside at a food cart conference in San Francisco.

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

02:20 It was incredible.

02:21 It really was.

02:22 And I got to tell you, I think more conferences should follow this style.

02:27 I know if you got a conference in Minnesota in the winter, you probably can't have it outside.

02:31 But boy, what a neat way to have a conference in the age of COVID where people felt comfortable.

02:37 And honestly, forget COVID.

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

02:42 Oh, yeah.

02:43 I'm looking forward to going back this year in September.

02:45 Oh, yeah.

02:46 It's going to be epic.

02:46 Okay.

02:47 Anyway, that was really great to meet you there.

02:50 And now we're here to talk about testing.

02:52 It's really, you know, what a surprise that you're on the show to talk testing in Python.

02:58 Who would have thought of all people?

03:00 Yeah.

03:01 And people may know you from your Automation Panda work and blog and stuff like that, right?

03:07 So let's get started with your story.

03:08 How do you get into programming in Python?

03:10 And maybe just kick it off by talking about Automation Panda.

03:12 It's maybe a good place to set the stage.

03:14 Sure.

03:14 So I'll start with how Python, then I'll talk about why Automation Panda.

03:18 So I first started programming Python in high school.

03:20 This was around 2005.

03:24 I think Python 2.3 was the new version.

03:28 I was taking a survey of programming languages course.

03:32 We did a whole bunch of things.

03:33 And the instructor really liked Python.

03:34 So I picked it up a little bit.

03:36 Nice.

03:36 Didn't do much other than toy around.

03:37 Then I didn't do anything with Python until about 2015, when I joined a new company in my

03:43 area called Max Point, and their three languages were Java, C#, and Python.

03:47 And so I picked up Python and I really, really, really loved it again.

03:52 And that's when I went heads down into it.

03:54 I've spoken my first Python conference.

03:56 It was PyData Carolinas 2016, right in my backyard in Durham.

04:00 IBM was hosting it.

04:01 Yeah.

04:01 Then I attended PyCon 2018, and the rest was history.

04:04 I think a lot of people out in the audience listening, many of them have never been to

04:09 either a regional or near international conference, PyCon.

04:14 And so many people I talked to are like, I can't, I didn't think I was really good enough

04:19 to go or experienced enough to go or whatever.

04:21 And then they say, but I went and it was amazing.

04:24 And now I feel so much more part of the community, right?

04:26 Like I just want to encourage people to, you know, like it sounds like you went there and

04:29 you're like, oh my gosh, I forgot how cool this place was, this ecosystem was.

04:33 And like, I'm in.

04:34 Absolutely.

04:34 I mean, that's one of the best ways to engage the Python community.

04:37 Find your local meetup, find your regional conference or attend the biggins.

04:40 Yeah.

04:41 And unfortunately, there are people who are far away from any of those, but there's really

04:46 good online meetups.

04:48 Like I was just on the PyIndie one and they've, they're doing a hybrid now with the Six Feet

04:54 Up folks.

04:54 And it's like, they've got their, their real in-person meetup, but then you can participate

04:59 and you're up on the screen with the group and whatnot.

05:02 So there's still ways to do it.

05:03 Even if you feel like, well, I live in small town outside of the small town that has no meetup,

05:09 right?

05:09 I'm the one Python person that I possibly know.

05:11 It's still an option.

05:12 Absolutely.

05:13 Okay.

05:13 So you dive in, get into it.

05:15 And you've basically been, been working in it on and off in different aspects for quite

05:20 a while now.

05:20 Indeed.

05:21 Indeed.

05:21 I consider Python my favorite programming language.

05:23 Funny fact, until my current job from about 2016 through 2021, my main programming language

05:31 at work was actually C#.

05:33 And so people would ask me, so what do you do with Python at work?

05:35 I say nothing.

05:36 And they think I'm joking.

05:37 I'm like, I'm more of a polyglot.

05:40 One can dream, but no, it is not true.

05:41 I don't know.

05:42 Yeah.

05:42 I mean, I do Java, JavaScript, Python, C#, you name it.

05:46 Way long ago, I did test automation in Perl for a couple of years.

05:49 That was fun, quote unquote.

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

05:54 Oh my gosh.

05:55 Oh my gosh.

05:56 Sorry.

05:57 I didn't really give you flashbacks.

05:58 It's all right.

05:59 That is the one gem that's buried in Perl, I would say.

06:01 I mean, Perl, every language has strengths and weaknesses.

06:04 Perl strength is reg X by far.

06:06 Yeah, sure.

06:07 Yeah.

06:07 Anytime I hear people talking about how much they use Perl or love Perl, it's got a really

06:12 strong text understanding element to what they were doing.

06:15 Mm-hmm.

06:16 Mm-hmm.

06:17 Nice.

06:17 Well, you spoke about your jobs and doing the C# thing.

06:20 And I don't think that that's necessarily that big.

06:23 I don't think it's a negative.

06:24 You know, there's tons of people who they go to work and work in one language and then

06:27 they maybe come back and they love Python or vice versa.

06:30 Maybe they do Python and they love JavaScript.

06:33 I don't know.

06:34 We could get them help.

06:34 Just kidding.

06:36 But I know that for a lot of people, the dream is like, how do I do Python full time?

06:40 For now, it's a hobby.

06:42 But how do I like, I'm writing a blog, I'm doing some projects, but I want to do that as

06:46 my job.

06:46 Right.

06:46 So yeah, you kind of made that transition again, in a sense.

06:50 Yep.

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

06:53 Yeah, that's awesome.

06:56 So tell us about what you're doing now.

06:58 Sure.

06:58 So I'm a developer advocate at a company called Apple tools.

07:01 Apple tools focuses on automated visual testing.

07:05 So if I got this right, there you go.

07:07 You got it.

07:07 Yeah.

07:07 Some people think I work at Apple.

07:09 It's like, no, no, no.

07:09 Apple tools.

07:10 Apple tools.

07:12 A-P-P-L-I tools.

07:14 I'll put it in the show notes.

07:15 Sure, sure.

07:15 And so the premise is a lot of traditional functional testing is either your manual tester

07:22 banging on a keyboard, looking and clicking through.

07:24 Or if you're doing automation, you're scripting it, right?

07:26 With a tool like Playbrite or Cypress or Selenium WebDriver, whatever.

07:30 They're all good tools.

07:31 But when you're using a browser automation tool, typically you're faking like the clicks

07:36 and the typing.

07:37 And then you're scraping the DOM of the page to get things like text or attributes of HTML

07:43 tags or classes.

07:44 And you're doing some sort of assertions on those.

07:47 Right.

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

07:52 Oh, well.

07:52 Nothing.

07:52 Yeah.

07:53 Or you got to do a little bit, something more complicated to scrape it.

07:56 But still, you're just like comparing text, right?

07:59 Exactly.

07:59 Exactly.

08:00 What about CSS?

08:00 What about visuals?

08:01 What about JavaScript events being linked up?

08:04 Exactly.

08:04 And so in that sense, the assertions you're doing are really a bare minimal validation of

08:10 the page.

08:10 The way I like to describe it is most traditional automated scripts will work if you rip the entire

08:16 CSS off the page.

08:17 It would look butt ugly, but your test scripts will go through.

08:20 So the question is, is that really proving that it works?

08:23 From a human aspect, no.

08:25 You would expect to make sure that things like your layout are good, that your buttons are

08:29 there, that your text is aligned.

08:31 All the colors are right.

08:33 And so that's where automated visual testing comes in, right?

08:36 That you would take snapshots of different views of your web or mobile apps, whether it's

08:41 a full page, whether it's a section of a page.

08:43 And then every time you make changes, you run the tests again, and they'll take checkpoint

08:47 comparisons to point out, here's what has changed.

08:50 And then you as the tester can decide, is that good or bad?

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

08:57 Yep.

08:57 It's a little bit stronger than just like a pixel to pixel comparison, right?

09:01 Because if you had a padding shift by two pixels, all of a sudden everything's blown up, right?

09:05 Apple tools uses.

09:07 Yeah, exactly.

09:07 Like if it has the time of day up there and the time it goes from like nine to 10, it'll

09:12 shift everything a little bit.

09:13 Text changes like that too.

09:14 So what Apple tools does is it uses visual AI to really pick out the things that would be

09:19 noticeable to a human eye.

09:20 So if you have a small shift, not a big deal.

09:22 You can set ignore regions, like for certain text areas, like it's the time of day or those

09:26 kinds of things.

09:27 So you can really hone these visual assertions that you're making.

09:31 Other thing you can do is because they're taking snapshots of the page, it's like a full

09:35 DOM capture.

09:35 It's not just a pixelated screenshot.

09:37 You can take those snapshots and re-render them on different browser configurations.

09:41 So, you know, for example, I'm using a Mac.

09:43 I can test on Chrome and Firefox and Safari and Edge now, but I can't test IE.

09:50 You know, well, you could take that snapshot, send it up to the Apple tools cloud.

09:54 And then in there, you can test it on IE.

09:56 There you can test it on mobile platforms.

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

10:00 Oh, exactly.

10:01 Right.

10:01 That's the other one.

10:02 If you're on Windows, you want to test Safari, but you can't.

10:04 Boom.

10:04 Apple tools ultra fast grid is a way to do that.

10:06 So there's a lot of really cool stuff you can do with visual testing.

10:10 That sounds fun.

10:11 Yep.

10:11 And so what I do at Apple tools, I'm a developer advocate.

10:14 So I stand between company and community.

10:17 I help the community understand good testing practices.

10:20 What is visual testing?

10:21 Help them get the most out of using Apple tools.

10:24 And also to be in the community to advocate for them.

10:27 Here are the problems.

10:28 Here are the needs.

10:29 Here's the struggles.

10:29 How can Apple tools help me?

10:30 Right.

10:31 I tell people our tool does this.

10:32 They say, we don't need that solved.

10:34 We need this other slightly different thing solved.

10:36 Yep.

10:37 Yep.

10:37 And you're like, all right, I'll talk to the team.

10:39 That kind of stuff, right?

10:40 Yeah, exactly.

10:40 Yeah.

10:41 I think the DevRel developer evangelist role is super fun.

10:44 It sounds like a really neat.

10:46 If you're a little bit extroverted, you like talking to people, you love code.

10:50 Yeah.

10:50 I mean, it's great.

10:51 Yep.

10:52 So one other thing I do want to mention with the whole Apple tools, DevRel thing, Apple tools run something called test automation university, which is a free platform full of online courses about testing automation and everything on that topic.

11:05 So we got some of the best instructors in the world who have these courses.

11:08 I've taught three of the Python courses.

11:12 You know, I would recommend folks check it out.

11:14 Test automation university, TAU.

11:16 It's good stuff.

11:17 All right.

11:18 Automation Panda.

11:19 Oh my goodness.

11:20 So yes, I also happen to be called the automation Panda.

11:23 That's just me.

11:24 You know, there's no like company or anything.

11:26 It's just my moniker.

11:28 It's my Twitter handle.

11:28 It's my blog.

11:29 Or the reason I started the whole automation Panda thing back in 2016, I got my first position as a senior level engineer.

11:37 And I thought, wow, this is great.

11:38 I've achieved my career dream.

11:40 I'm senior level.

11:41 People going to listen to me now.

11:42 What's next?

11:43 Like, oh, hmm.

11:45 Up until that point, all the work I'd ever done had been behind company proprietary walls.

11:50 Even if that work had not necessarily been proprietary or secret or anything like that.

11:56 You know, I got sick of rewriting the same thing, wiki pages across multiple teams.

12:00 So I was like, you know what?

12:01 Maybe I can do something more public facing.

12:03 Maybe I can write those wiki pages on something like a blog that everyone can just Google for and find.

12:08 Especially me, because I don't want to have to repeat the same things over and over.

12:11 And so I was like, okay, I'll start a blog.

12:13 And I needed a catchy name because you go to, you know, whatever website to register your domain.

12:19 And I'm like, well, andrewknight.com is not available.

12:22 And nobody's going to remember Andrew Knight anyway.

12:24 Let me come up with something catchy.

12:26 And I just landed on Automation Panda.

12:28 Automation for test automation.

12:30 Panda, because pandas are awesome.

12:32 Yeah.

12:32 And there we go.

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

12:37 As I think across the different animals throughout the animal kingdom, they are very finicky about a failed app.

12:46 I suppose.

12:46 Push or whatever.

12:48 I'm just kidding.

12:49 No, that's awesome.

12:50 And I certainly know you through this.

12:52 And you've done a lot of general advocacy for testing in the Python space there.

12:57 Yeah.

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

13:00 That is true.

13:02 Exactly.

13:02 Well, I mean, I think that that's often how people get into these roles.

13:06 You think there's probably a lot of people that are thinking, like, I would love to have that role.

13:11 So I'm going to try to apply so I can get that role.

13:13 And, you know, you did a bunch of public speaking and presentations.

13:17 And I'm sure they saw that.

13:18 Like, this guy is great.

13:20 We just need to have him on our team.

13:21 You know?

13:22 And I got hired doing in-person developer training because I was speaking at user groups and meetups and conferences and blogging.

13:31 And they're just like, I see you doing this for free.

13:34 Would you like a job to do it?

13:35 I'm like, that sounds awesome.

13:37 Let's do that.

13:37 Indeed.

13:38 So, yeah, it's definitely advice people can take sort of as a path forward.

13:42 Oh, yeah, definitely.

13:43 If they want to end up where you are, yeah.

13:44 When you generate content, that becomes your electronic business card.

13:49 That's how people get to know you.

13:50 And so if you do the things you like, the things you like will start coming to you.

13:54 Absolutely.

13:54 All right.

13:55 Now, how about we talk a little bit of testing?

13:59 Let's do it.

13:59 Yeah.

14:00 So the kind of testing that we're talking about here is somewhat related, actually, to your current job.

14:07 Yeah.

14:08 Apple tools, right?

14:09 Indeed.

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.

14:21 And if I pop two on and pop it off, it's going to be the second one.

14:24 Okay.

14:25 Our app is working, right?

14:26 It's trying to understand more of an integration black box level of testing, would you say?

14:32 Correct.

14:33 Correct.

14:33 I always say there is a big difference between testing code and testing features.

14:38 Testing code is what we would think of as white box or unit testing or maybe sometimes subcutaneous testing where you're testing to make sure that the implementation of whatever code you wrote, be it a function or method or something else, is working according to specification.

14:53 Like, okay, I have a function, an absolute value function.

14:55 Let me make sure that, you know, I have a table of inputs that meet the expected table of outputs, right?

15:00 Input, rank it up.

15:01 Output doesn't match.

15:02 You know, that would be unit testing.

15:04 And so it's very good for pinpointing things quickly, right?

15:08 Unit tests are very fast.

15:09 It catches problems at their source.

15:11 But it doesn't test things like, okay, can you actually complete the workflow that this whole big application is designed to do?

15:17 That's where feature testing comes in.

15:19 That's where you have to do something black box.

15:21 Unit testing is good when you are focused in on a part of the app.

15:25 Like, this part is the part that checks whether or not I can access this page, whether or not the user's logged in.

15:31 So let me try to request it with a user that's not logged in.

15:34 Let me try to request it with a user that is.

15:36 How about now one with whose one's logged in but doesn't have access through some role thing?

15:40 Right?

15:41 Like, that is fine.

15:42 But most applications, as they grow, become like Lego pieces that click together, right?

15:49 And if you think about web apps or APIs or I don't even want to think about microservices, you know, they become these things like, well, here's the database with its schema and constraints.

16:02 And here's the data layer.

16:04 And here's my view method.

16:06 And then, oh, here, these are the routes that are set up based on this view.

16:09 And here's the static folder for the JavaScript.

16:11 And then it renders and just here's the HTML template.

16:14 Like, 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.

16:22 And somehow I feel like that's OK because they could get out of sync.

16:25 Exactly.

16:25 Exactly.

16:26 This portion of Talk Python to Me is brought to you by Microsoft for Startups Founders Hub.

16:33 Starting a business is hard.

16:35 By some estimates, over 90% of startups will go out of business in just their first year.

16:40 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.

16:49 Microsoft for Startups Founders Hub was born.

16:52 Founders Hub provides all founders at any stage with free resources to solve their startup challenges.

16:59 The platform provides technology benefits, access to expert guidance and skilled resources, mentorship and networking connections, and much more.

17:07 Unlike others in the industry, Microsoft for Startups Founders Hub doesn't require startups to be investor backed or third party validated to participate.

17:17 Founders Hub is truly open to all.

17:20 So what do you get if you join them?

17:21 You speed up your development with free access to GitHub and Microsoft Cloud computing resources and the ability to unlock more credits over time.

17:29 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.

17:39 Through Microsoft for Startups Founders Hub, becoming a founder is no longer about who you know.

17:45 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.

17:58 You'll be able to book a one-on-one meeting with the mentors, many of whom are former founders themselves.

18:03 Make your idea a reality today with the critical support you'll get from Founders Hub.

18:09 To join the program, just visit talkpython.fm/founders hub, all one word, no links in your show notes.

18:14 Thank you to Microsoft for supporting the show.

18:17 Having that full application ready to go and you're testing it as if you were a user is very, very valuable.

18:26 It can be painful to set up.

18:28 It can be painful to think about all the scenarios to do, but it is also incredibly valuable in the results you get from it.

18:33 Yeah.

18:34 And I made the snarky comment about like a view or react front end as well.

18:38 Yeah.

18:38 Yeah.

18:38 Well, which really requires a little bit more of a test that understands the behavior rather

18:44 than just creating like a flask 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.

18:55 Yes.

18:55 Yes.

18:56 You need to pull up the page, load it in a browser and see what it does.

18:59 And, you know, you mentioned, I know this is the top Python podcast.

19:03 And so we love Python.

19:04 I love Python.

19:05 But in the web space, it's inevitable, unless you're using HTML or something.

19:09 Ha ha ha.

19:10 That Python is going to test JavaScript at some point.

19:12 Right?

19:13 Yeah.

19:14 They're going to crash together definitely in the web space for sure, unless you are purely

19:18 on the API side.

19:19 And who knows?

19:20 Probably somehow still it'll worm its way in there.

19:23 So traditionally, this kind of testing has been done by pulling up a browser.

19:28 It could be several levels.

19:30 It could be, okay, I get my feature implemented and I go click, clickety, clickety, click.

19:34 Seems like it's working.

19:35 Let's push it.

19:36 Like that's, let's call that level zero testing.

19:39 Actually, that's level like 0.1 because level zero is just make the feature change and push

19:43 it.

19:44 And then we'll see whether it crashes, right?

19:46 No test.

19:47 No test is level zero.

19:48 But then just above that is, I kind of sort of clicked around in the area that I think I

19:53 might have affected to see that it works, right?

19:55 Maybe take it from there.

19:56 Like, 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.

20:01 There is always a place for manual testing.

20:04 The place for manual testing is what I would consider exploratory testing because it's

20:08 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

20:19 to handle things like good design, judging design, judging user experience.

20:23 Does it feel laggy or is it responsive?

20:26 Exactly.

20:26 Exactly.

20:27 Performance issues and stuff.

20:28 And so people, like they start clicking and typing.

20:31 It's immediate, you know?

20:33 Like if anything is laggier than like 0.4 seconds or something, I forget the name of

20:38 that threshold.

20:38 That's categorically bad.

20:40 What we don't want to do is have the bulk of our testing coverage done that way.

20:47 We don't want to have the, let's say like the majority of our functional test cases executed

20:52 manually.

20:52 Because the idea of a test case, it's a well-defined procedure that you step through one through

20:57 and you do the steps and you make sure it works.

21:00 That kind of testing is where we might want to quote unquote level up to something like

21:03 automation, right?

21:04 Where you have these complimentary practices of you have automation do the rote, repetitive,

21:10 but still necessary checks along the way.

21:13 And then have your humans be creative in exploring and be able to judge the things that a script

21:18 can't necessarily judge for you.

21:20 Right.

21:20 That's kind of where that goes.

21:21 It would be lovely to leverage continuous integration and tools like that all over the place.

21:26 And if you don't have at least some basic level of automation, that's more or less inaccessible

21:32 to you, right?

21:33 Like, so let's take an example of, I've got a Django CMS that I built and it's open source.

21:38 And I want to allow people to send PRs to me to contribute back to this general CMS like

21:44 WordPress, but with Django press, I'll just make a random term.

21:48 It probably exists.

21:49 Who knows?

21:49 But like, imagine my Django press, I want to allow contributors and they're going to submit

21:53 stuff.

21:53 If I don't have something a little bit like the testing you're describing, then every PR,

21:59 I've got to go download it, try it out and do those things.

22:03 And as opposed to, no, the test didn't pass because you broke this thing.

22:06 First fix that, please.

22:07 Exactly.

22:08 Your automated test suites are your safety net and they should account for a very high

22:14 percentage of the coverage that you would want in your testing, right?

22:19 The idea is the automated tests will do almost all the kinds of things.

22:23 And then you would just have yourself or someone else go in and just kind of poke around real

22:28 quick, make sure everything is still good.

22:29 There's an, let me try the, okay, good, you know, and then feel good because you spent a

22:34 little bit of time, sanity check, making sure everything is still good.

22:37 Good from a user experience perspective.

22:38 While you had the battery of your automated suites batter the crap out of whatever changed

22:43 us when it, and it's like, Oh, they all passed.

22:46 Yeah.

22:46 Yeah.

22:47 Yeah.

22:47 I'm 95% sure we're okay.

22:49 Now let's go from there.

22:50 Yeah, exactly.

22:50 You can also hone in on the really important things, right?

22:53 Like in your CMS thing, maybe there's a reporting section that reports page hits over time or if

22:59 it goes down, that's not great.

23:00 But if the main page or main site won't even load, that's worse than the reporting being

23:06 screwed up.

23:06 Right.

23:06 So you can, you can focus in on those areas and really put the energy where people are going

23:12 to notice and consider it fully broken.

23:14 Basically.

23:14 Indeed.

23:14 Indeed.

23:15 All right.

23:15 So the tools of the trade traditionally have been Selenium for this type of thing, right?

23:20 And not to bash on Selenium anyway, it's, it's pretty awesome, but we're going to talk about

23:24 some sweet new stuff as well that also works with Python in nice ways.

23:28 Indeed.

23:29 Yeah.

23:29 So maybe tell people real quick about Selenium and then we'll talk about Playwright and you

23:33 can compare those.

23:34 Absolutely.

23:34 So as you said, Michael, Selenium has been the classic browser automation tool.

23:40 It's been around for, oh gosh, well over a decade now.

23:44 It's hard to believe.

23:45 Almost like two decades inch.

23:48 I mean, the early, very, very early, early things that ultimately became the Selenium

23:53 projects.

23:53 How Selenium works is that you will have your browser, whether that's Chrome.

23:59 IE, Firefox, RE, what have you.

24:01 There's the browser.

24:02 Then there is this web driver executable that acts as a proxy between the browser and your

24:08 test automation code.

24:09 And then in your test automation code, you have language bindings that will send requests

24:14 to the browser or the Selenium web driver executable.

24:17 It used to use a JSON protocol.

24:19 I think it's Selenium before they might've changed some things.

24:21 So I don't remember exactly.

24:23 Basically, you send, you send requests to the thing, its proxy goes to the browser, performs

24:27 whatever thing you wanted.

24:28 Did you want to click?

24:29 Did you want to get text?

24:30 Sends the response back through.

24:31 And so that's how your automation can control the browser.

24:34 This is back and forth between browser and your automation through this, this proxy executable.

24:40 Selenium is an open source project.

24:42 So everything is available online.

24:44 They have multiple language bindings, not just Python, Java, JavaScript, Python, C#, Ruby.

24:51 I don't know if there are any others, but those would be like the big five.

24:54 What else?

24:55 What else?

24:55 Not only is Selenium open source, but it is also open standards and open governance.

25:00 Those might be new things or new phrases for some people.

25:04 So let's go over there real quick.

25:06 Open source means that the source code for all the implementations for Selenium web driver,

25:13 as well as the other tools, Selenium ID and grid, which I'll talk about in a moment.

25:17 Those are all GitHub.

25:18 You can check out the source.

25:20 You can look at it.

25:20 You can fork it.

25:21 You can make changes.

25:22 You want to contribute to the main project.

25:23 You can submit pull requests.

25:25 And so that is all open and free.

25:28 Open standards.

25:29 What does that mean?

25:30 The way Selenium works is it uses the web driver protocol to communicate with browsers.

25:36 Web driver as a protocol is a W3C standard.

25:40 It's something that all major browser vendors are supposed to conform to.

25:44 And the reason, and that was a hard fall battle to get that to be a W3C recommendation.

25:48 What that means is that hopefully in perpetuity, web driver will work with every major browser

25:54 out there, right?

25:55 So that there's this guarantee.

25:56 We get a Zerodium instead of a Chromium in the future.

25:59 Theoretically.

26:00 Exactly.

26:01 Theoretically it'll come with that, right?

26:03 So that we could use the same protocol, meaning we could use the same tools to automate the

26:06 basic browser interactions.

26:07 So that's open standards.

26:09 Open governance means that Selenium is not controlled by any single party or private entity or single

26:16 company.

26:16 The way that the Selenium project is governed is by a consortium of open source contributors

26:23 and collaborators.

26:23 I know many of these folks, they span multiple different companies.

26:27 And so that way it's not like one person can control it.

26:30 One person can't kill it.

26:32 And again, everything is open.

26:34 So it's not like it's a secret little cabal that everybody's scheming together.

26:37 No, you can go read the meeting notes or the monthly meetings of the Selenium team.

26:41 That's Selenium in a nutshell.

26:42 Most times when people talk about Selenium for browser automation, that means Selenium web

26:46 driver.

26:46 That's like when you pip install Selenium in Python, you're getting the Selenium web driver

26:51 package.

26:51 That's the Python language bindings for the web driver protocol that you can go communicate

26:56 with the browser.

26:57 The other two projects Selenium IDE is a basically like a visual builder.

27:03 So instead of you trying to figure out your expats and everything, you can use Selenium IDE to kind of

27:07 create a visual builder for your test case steps.

27:10 And the other project they have is Selenium grid, which is this scale out solution.

27:15 So rather than running all the browsers on your local machine for testing, because that will max out your system resources very quickly.

27:23 If you parallelize, you can distribute that remotely.

27:26 So you can have like a cluster of nodes that have IE, some of them have Chrome, some have Safari.

27:32 And so then you make remote requests and do the automation that way.

27:36 So that's Selenium.

27:37 Okay.

27:38 Very cool.

27:39 And like you said, it's been around for a while.

27:41 And then the new one on the block is Playwright.

27:46 And it's conceptually people should think of it like similar to Selenium, I think is your mental model, I would guess.

27:52 But then it has some differences and advantages.

27:55 One of which is it had 10 years of experience to build upon.

28:00 True, true.

28:01 Maybe tell us about Playwright.

28:02 Sure, sure.

28:02 So Selenium and Playwright at their core, the highest level are both browser automation tools.

28:08 They go in, they do the clicks, they do the scrapes, you know, they send back the answers.

28:14 So in that sense, they're similar.

28:16 And also the main, I should also just caveat this, the main use case for both Selenium and Playwright is test automation.

28:21 You could use it for any kind of automation, but primarily people use it for testing.

28:25 Right, okay.

28:25 And I will talk mainly in the domain of testing.

28:28 I mean, you could use this to like, if you wanted to, I don't know, like refresh a page every hour and scrape it using Scrappy or something.

28:36 But anyway, let's talk, just keep the focus on testing.

28:39 I kind of would have like, in my history, would have liked to automate registering for college classes so I could get the 10 a.m. classes, not the 7.30 a.m. calculus class.

28:49 Yep, yep.

28:49 If only, if only, right?

28:52 So Playwright, Selenium, both browser automation tools.

28:55 But the ways in which they go about that are different.

28:59 Selenium uses that web driver protocol, which kind of operates outside the browser, right?

29:04 Playwright uses debug protocols.

29:08 So basically, Chrome dev tools and Firefox's equivalent and all that.

29:11 That's what Playwright focuses on.

29:13 In that case, Playwright can access things about a browser that either Selenium can't or Selenium struggles to.

29:21 It also makes Playwright run a bit faster than Selenium.

29:26 One of the big complaints about Selenium-based tests is that they are slow.

29:31 Now, this is due to the nature of them being black box that you need to have the whole system up.

29:36 The fact that...

29:38 Right.

29:38 Launch your entire browser and then we're going to send messages and then shut it down and then launch it again for the next test.

29:43 Right, right.

29:44 Like that kind of stuff, right?

29:45 So there is, based on the nature of UI or black box testing, there is sluggishness there.

29:50 But at the same time, like you just mentioned, you know, the whole browser setup thing can be kind of slow.

29:55 Playwright has some optimizations there that are pretty...

29:57 So it can be a little bit fast.

29:58 Another big difference between Playwright and Selenium, Selenium WebDriver is meant to be more of a low-level interface.

30:08 So the interactions that you would do with Selenium are very raw.

30:13 Like when you do a click, it'll send a click event and that's it.

30:17 It doesn't wait for the thing to be received.

30:19 It doesn't wait for the page to load or do anything magic.

30:21 It just goes.

30:22 And so with Selenium, you have to do a lot of explicit waiting for things.

30:28 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.

30:35 The element might not be loaded and your test will go kaboom.

30:39 And then your test suite gets criticized for being quote-unquote flaky.

30:43 Yeah, absolutely.

30:44 Well, this is like what happens in the JavaScript world.

30:47 It's not the instant the page shows up.

30:49 It's got to then bring down the JavaScript.

30:51 Then maybe the JavaScript talks to some API and then it comes back and it binds to some stuff.

30:55 Like there's a bunch of network steps with built-in latency there.

30:59 Exactly.

31:00 That is the pain point of all types of black box testing.

31:04 There are inherent race conditions.

31:06 And when you do test automation in that type of space, then you need to handle appropriate waiting for those race conditions or else your test will be flaky.

31:16 And so in that sense, Selenium WebDriver, the tool does get a bad rap for being flaky when it's not WebDriver itself.

31:22 99% of the time, it's actually the tests written using WebDriver that don't have those explicit waits in there.

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

31:34 And so, yeah.

31:35 Exactly.

31:36 And so that's exactly where I was going.

31:38 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 Like that's kind of what you think.

31:48 Nope.

31:49 No, no.

31:49 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, right?

32:01 Especially when they're newer to it.

32:02 Whether that is a manual tester who's learning automation for the first time or a developer who's crossing over to automate some tests, you know?

32:10 Yeah.

32:11 Well, I mean, maybe you're just testing your local dev machine running on a local dev server where there's no network latency.

32:18 And then you go and test against your microservice deployed cloud CDN thing.

32:24 And it just doesn't behave the same, right?

32:26 Exactly.

32:26 It could have been working and working and working and working.

32:28 And now it's flaky.

32:29 Exactly.

32:30 So with that in mind, with Selenium being that low-level kind of tool, I mean, I've even talked and heard from the Selenium people on this.

32:37 Their thought is WebDriver is meant to be a low-level tool that you have to handle all those things yourself.

32:43 And they even encourage you, you have, you know, layers and frameworks on top of Selenium that will handle that kind of stuff for your needs.

32:50 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.

33:00 Like in Java, you have Serenity BDD, which has a layer over it like that.

33:04 There's something called Selenide.

33:05 You know, there's tons of different little projects out there.

33:09 Sure.

33:09 Compared to Playwright.

33:10 Playwright is not a low-level interaction tool.

33:16 Playwright is meant to be more modern, more refined, more high-level, more do-things-for-you, where the framework is there to help you.

33:23 And so when it comes to waiting, most of the time that you need to do waiting in Playwright, Playwright handles it for you automatically.

33:31 So for any single interaction where you are interacting with an element, depending on that type of interaction, there is a specific kind of wait automatically built in for that element, that target element to be ready before it does anything with it.

33:45 You know, so before you go to click an element, Playwright's going to be like, whoa, whoa, whoa, let's wait about five seconds until it appears on the page.

33:51 And once that thing appears, it's a smart wait.

33:54 So boom, it'll dive in and do it then.

33:56 So you don't have that flakiness that perbades so many older test suites.

34:01 It's so good.

34:01 And when your tests are flaky, then you just, doesn't matter if it fails, whatever.

34:05 It fails sometimes.

34:06 Right?

34:07 As opposed to, oh no, the test failed.

34:08 What happened?

34:09 What went wrong?

34:10 Mm-hmm.

34:10 Mm-hmm.

34:11 Exactly.

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

34:17 Yes.

34:18 This portion of Talk Python to Me is brought to you by the Compiler Podcast from Red Hat.

34:25 Just like you, I'm a big fan of podcasts.

34:28 And I'm happy to share a new one from a highly respected and open source company, Compiler, an original podcast from Red Hat.

34:36 With more and more of us working from home, it's important to keep our human connection with technology.

34:41 With Compiler, you'll do just that.

34:43 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.

34:51 These conversations include answering big questions like, what is technical debt?

34:55 What are hiring managers actually looking for?

34:58 And do you have to know how to code to get started in open source?

35:02 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.

35:11 I just listened to episode 12 of Compiler, How Should We Handle Failure?

35:15 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.

35:25 It's a conversation we can all relate to, I'm sure.

35:27 Listen to an episode of Compiler by visiting talkpython.fm/compiler.

35:32 The link is in your podcast player's show notes.

35:34 You can listen to Compiler on Apple Podcasts, Overcast, Spotify, Pocket Cast, or anywhere you listen to your podcasts.

35:41 And yes, of course, you could subscribe by just searching for it in your podcast player,

35:45 but do so by following talkpython.fm/compiler so that they know that you came from Talk Python To Me.

35:51 My thanks to the Compiler Podcast for keeping this podcast going strong.

35:57 Before we dive in too much to Playwright, just a couple of questions that I think there that are interesting and worth covering.

36:05 Dave Sharp says, I use Selenium for some headless browser tests and automations.

36:10 Is that possible with Playwright?

36:11 Yes.

36:11 Yeah.

36:12 Yeah.

36:12 So real similar, I think the API is probably a little cleaner as well, as we'll see in a minute.

36:16 Then Micah also says, absolutely can recommend Playwright.

36:20 And the robot framework side browser library is built on Playwright and Selenium library on top of Selenium.

36:27 Faster and 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.

36:34 Let's maybe just highlight some of the, you've introduced it pretty well across browser because it does Chromium WebKit and Firefox.

36:42 And when you say Chromium these days, you're like 96% of all the browsers, sadly.

36:47 That covers a lot, right?

36:49 That's not just testing for Chrome, but that's testing for Edge, Brave, Vivaldi, et cetera, et cetera, cross-platform.

36:57 I want to go back to browser because there is an interesting difference here to note between Selenium and Playwright.

37:03 When you use Selenium, you're testing the full browsers, right?

37:06 You're testing Google Chrome.

37:07 You're testing Mozilla Firefox, Microsoft Edge.

37:10 Does it even load up like extensions and stuff like that?

37:13 Or is it just, is it more bare?

37:14 Is it like maybe just below your customizations?

37:16 In Selenium, it's the full browser, whatever you've got.

37:18 You can do things from a command line to kind of like play with certain things like what user profile use, what user data directory and all that.

37:25 But essentially, the browser that's installed on your machine is what Selenium WebDriver would use.

37:30 But in Playwright, it doesn't use those quote unquote stock browsers.

37:33 Playwright uses browser projects.

37:35 So with Playwright, you are not testing Google Chrome.

37:38 You are literally testing the Chromium project.

37:41 You're not testing Mozilla Firefox.

37:43 You're testing the open source Firefox project.

37:45 You're not testing Apple Safari.

37:47 You're testing the WebKit project.

37:49 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.

37:58 And so when Playwright runs, it's running against those.

38:01 In a sense, it's a more pure stripped down, just the essence of the rendering engine, JavaScript.

38:07 Exactly.

38:07 VM and stuff.

38:08 Exactly.

38:08 So it is.

38:10 That's really nice.

38:11 It's an opinionated take.

38:12 You seem to have a very positive view of that, Michael.

38:15 I do.

38:15 Yes.

38:16 I think it's cool.

38:17 I think it's awesome.

38:18 I think it's lighter weight.

38:19 But I would also caveat they may not be usable in all contexts.

38:23 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.

38:34 It's out there.

38:35 It exists.

38:36 Maybe you want IE 11 and you've got to just run that because they're they're crummy SharePoint installation from 10 years ago.

38:43 Stuff like that.

38:43 Unwilling to upgrade like anything but that log into it or some weird thing like that.

38:48 Right.

38:48 Exactly.

38:48 So anything like that may be a showstopper for folks who want to use Playwright.

38:52 My gut tells me that's a very, very small sliver of the wider industry, but it is something to call it.

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

39:01 Yes, exactly.

39:02 Exactly.

39:02 Sure.

39:03 Okay.

39:03 Across platform, Windows, Linux, Mac plus CI and headless.

39:08 That was sort of touched upon in Dave's question, but maybe discuss this headless versus headed idea of this, these types of frameworks.

39:17 Sure, sure.

39:18 So when you're the human and you open up your browser, that's headed mode.

39:21 Why is it called headed mode?

39:23 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 viewports you've got.

39:29 Headless mode is a way that you can run browsers without having it pop up on the screen and render all that stuff.

39:35 It'll still do the rendering.

39:36 It just won't graphically display that to you.

39:38 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.

39:46 Why?

39:47 Because it uses fewer resources.

39:48 It's a little bit faster.

39:50 Nobody is there to look at the screen when it pops up.

39:53 It's got a button.

39:54 Would you like to upgrade?

39:55 Yeah.

39:56 Yeah.

39:56 Chrome is great, but you should try Edge.

39:59 It has these new shopping.

40:00 No, I don't want that.

40:00 Go on.

40:01 Yeah.

40:01 Thanks.

40:03 I know that wouldn't happen in the project.

40:04 That might be more of a Selenium thing if you get like these weird, typically, you know, periodic pop ups, right?

40:09 From the browser vendors.

40:10 Indeed.

40:11 When headless modes first became popular, I want to say about like five years ago, like it really became popular with PhantomJS.

40:18 And then Chrome basically came along, did the same thing and killed the PhantomJS project.

40:22 The dude just like, I'm done.

40:24 Use Chrome instead.

40:25 Like TLDR on the GitHub repo.

40:27 I was like, wow.

40:27 Now all the browsers do this.

40:29 But it is a recommended practice that when you're running tests for credit, like in CI or something, you do headless mode.

40:35 Also, if you try to do headed mode in certain CI tools or GitHub actions, sometimes you might get these walkie errors like, you couldn't render this thing.

40:42 Yeah.

40:43 Or maybe like the desktop UI tools or frameworks are not set up to actually show windows or some weird thing.

40:49 But headed, you might want to see what happened.

40:52 Like if something goes wrong.

40:53 So you would use headed mode when you are developing the test automation on your workbench.

41:00 Like, you know, I've got Visual Studio Code open and I just code my test.

41:04 I want to run it real quick.

41:05 I want to see it pop up and dance through the page.

41:08 Right.

41:08 That's when I would use headed mode.

41:09 Also, interesting thing.

41:11 I believe by default, Playwright uses headless mode.

41:15 It's not something that you have to.

41:17 Yes.

41:17 I think you're right about that as well.

41:19 Yeah.

41:19 If you want a headed mode, you got a headless equals false or headed equals, I don't know.

41:23 We'll see it in a second.

41:24 We'll get to the examples.

41:25 But you got to opt in.

41:27 And then you already mentioned the Playwright API is TypeScript, JavaScript, Python, .NET, and Java.

41:32 And people are like, ah, I'm not using it.

41:34 It's not Python.

41:35 Well, the browsers aren't Python anyway.

41:37 So it's just like one more layer of who knows how many technologies are in there.

41:41 But like NumPy has a C layer.

41:43 This is like a layer to talk to the thing that does the work.

41:47 And it's a pretty nice API, as we're going to see in a moment.

41:49 And then you can also test mobile web, even if you don't have a mobile web thing, because it has native mobile emulation.

41:55 Yeah.

41:56 Correct.

41:56 That's all, you know, 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.

42:05 Very cool.

42:05 Test like responsiveness and like a bootstrap menu or something.

42:09 Auto-wait.

42:10 That sounds very promising.

42:12 It waits for elements to be actionable prior to trying to click them.

42:16 You already went into the flakiness and race conditions of all that, but that's pretty cool.

42:20 Web-first assertions.

42:22 What does that mean?

42:23 So that sounds good.

42:24 Yeah.

42:24 Yeah.

42:24 Yeah.

42:24 Because you're testing the web.

42:25 So that kind of goes hand in hand with auto-wait.

42:28 For those of you who are familiar with unit testing in Python, whether that's with unit test or pytest.

42:34 No, unit test has its like assert that library.

42:38 pytest, you literally just use the assert command in Python, right?

42:42 Assert this, assert that, all that kind of stuff.

42:44 When it comes to web testing or really any sort of black box testing, the basic kind of assert statements can be limited.

42:52 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.

42:59 That's basically what these web-first assertions mean.

43:01 In Playwright, there is an expect function.

43:04 It's in JavaScript.

43:05 It's in Python.

43:06 I think it's in the others.

43:07 But basically, you would say something like expect a certain locator to have a certain text value.

43:12 And what it'll do is it'll wait until said phrase has that text value or wait until this locator appears on the screen.

43:19 It's a more fluid kind of way of writing assertions.

43:22 And it also has that built-in waiting.

43:25 And they call it 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.

43:32 Not trying to shoehorn them into some fixed static Boolean condition.

43:36 Yeah, that's very cool.

43:37 Okay, and then the last selling point on resiliency here is tracing, configure tests, retry strategies, capture execution traces, videos, and screenshots.

43:48 So, yeah, we'll see some of the tooling, the GUI tools and stuff for this.

43:52 But, yeah, this sounds really nice.

43:54 Mm-hmm.

43:55 Mm-hmm.

43:55 If your test fails in CI and you get a video, they click there and then that gave a, you know, 400 or something.

44:02 In JavaScript instead of filling up this form, like, that sounds pretty nice.

44:06 Oh, yeah.

44:06 So, yeah, and that's a huge advantage that Playwright has over Selenium as well.

44:10 Like, in Selenium, you can capture screenshots along the way, but there's no built-in video capture.

44:15 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'll poop out a screenshot.

44:27 Or you can just be like, give me the whole dang video so I can trace through a watch.

44:30 I mean, screenshots are great.

44:33 Video is lit.

44:34 It's incredible.

44:36 It's like, oh, my gosh, they did it.

44:38 They planted the flag.

44:40 Victory.

44:41 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.

44:45 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.

44:50 Because, like, that's the thing.

44:52 Like, in olden times, I kid you not, when people did automation, they would literally push the button on the machine and just, like, watch it go.

44:59 Wait for it to finish.

45:00 And that was automation.

45:01 No, no, no, no.

45:02 Like, true automation is it's in some sort of CI system.

45:05 You know, it runs on a, after every pull request, after every commit, or maybe if the test suite is too big, it runs nightly or, you know, a couple times a week.

45:13 You are not there to watch it fail, right?

45:15 So you need all the evidence you can get.

45:18 What's the best evidence?

45:19 Video.

45:19 Video to see what's happening, and then you dig into logs.

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

45:26 Exactly.

45:26 And so, yeah, it's really good.

45:28 I love it.

45:29 Okay.

45:30 Stuff about running on modern platforms, but then let's talk the isolation.

45:35 I think that that's huge.

45:36 There's two things about sort of authentication and cookies and stuff like that.

45:41 It's pretty interesting.

45:43 But then just also the isolation, right?

45:45 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.

45:54 And this, you kind of like don't want to depend upon the last page you visited for browser tests.

45:59 And specifically with the isolation and Playwright and the browser context here.

46:04 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.

46:14 And the reason you do that, you open and close for every single test is because you want that isolation, right?

46:19 You don't want to share web browsers across tests because things can go wrong.

46:23 With Playwright, one of the optimizations is for the entirety of your test suite, you do only have one browser process.

46:30 So you only have one Chromium process.

46:32 It's at the beginning of everything you started up and it exists throughout all tests and you close it.

46:37 You're like, well, how, wait, doesn't that violate independence and isolation?

46:41 What Playwright does is it creates what's called browser contexts out of that.

46:44 So the slow part is...

46:46 It's like a new private incognito window sort of, right?

46:49 Yes, exactly.

46:50 It's basically like your own session, your own window, your own user account kind of thing.

46:55 Browser contexts are very quick to create and close.

46:58 So you don't have the like five second to 10 second startup and teardown time per test.

47:03 It's like a split second.

47:04 So that makes you be able to set up your test a lot faster.

47:06 And it's basically, it's like an incognito session.

47:09 So you have access to everything in your scope.

47:12 But if there are other contexts running at the same time, e.g. you're running parallel tests,

47:18 you can't access anything in the other sandboxes.

47:20 So it's safe.

47:21 And it's really a game changer for browser-based testing.

47:24 And as you mentioned, just like I have a quick count, I think I have six browser tabs

47:30 and a progressive web app open right now.

47:32 They don't interact, right?

47:34 I mean, that's just how browsers are built.

47:35 That if I visit playwright.dev and then some other...

47:38 Selenium, whatever, they don't get to spy on each other, right?

47:43 That's just how it works.

47:45 And so it leverages that to say, well, we can do more than one tab at once.

47:48 Let's go.

47:49 And all of your authentication or browser context, you know, any of the cookies you have protected by browser context.

47:55 So you can do a lot of really cool stuff.

47:57 It's not just you're on a different tab because that comes down to pages off of browser context, which is another thing.

48:03 But it's full context of what's going on.

48:07 Yeah.

48:07 Yeah.

48:08 Yeah.

48:08 Very cool.

48:09 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?

48:16 We're going to talk about the API next and go see that.

48:18 And the API is really nice.

48:20 But sometimes you're like, oh, what is that CSS selector?

48:23 And I've been writing CSS selectors for many years, so it doesn't bother me.

48:27 But I remember the beginning of like, what does it mean when there's the arrow versus not the arrow?

48:32 Or does it need the space or not the space between the dot and the preceding element?

48:36 You're just like, oh, I'd rather just go hit me with a stick.

48:39 I've done more content.

48:39 I just can't take this anymore.

48:41 I'm pulling my hair out.

48:43 So there's some tools like a code gen, sort of record my interactions and then generate Python or other language, I guess.

48:50 For me, that'll help a lot there, right?

48:52 Yep.

48:53 Maybe we could talk a bit about really high level.

48:55 Then we could like, we'll dive in.

48:56 We'll pull some pictures about it.

48:57 Sure, sure.

48:58 Yeah.

48:58 I mean, it's basically that like it fires up a browser.

49:01 You click through.

49:02 You say, I'm done.

49:02 And then poops out all the stuff you did in Playwright code.

49:05 Yeah.

49:06 Well, you talked about it using the dev tools.

49:07 It's very much like the inspect element of the dev tools.

49:10 Yep.

49:10 Okay.

49:11 And then there's an inspector, a similar, but also kind of like lets you step through and a trace viewer as well.

49:18 That's a little bit like the network tab, I guess, plus snapshots.

49:21 Yeah, yeah.

49:22 Screenshots.

49:22 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.

49:29 So you can kind of better trace through it after the test is done.

49:32 Live DOM snapshots and all that good stuff.

49:34 Okay, cool.

49:35 Let's maybe talk through some of the code and how it works.

49:38 Install.

49:39 Easy.

49:40 Know it.

49:41 Love it.

49:41 pip install it.

49:42 But it looks like there's two steps.

49:44 I pip install Playwright and then I playwright install.

49:46 Ah, yes, yes.

49:47 So pip install Playwright is what's going to give you the Python Playwright package.

49:51 I know that's a lot of P's.

49:52 What Playwright install does is it installs those browser projects, Chromium, Firefox, and WebKit.

49:59 Right, okay.

49:59 You can also, I think you can do Playwright install Chromium if you want just one, right?

50:03 Correct.

50:04 You can focus in.

50:04 Yep.

50:04 You can pick the one to install.

50:06 Yeah, but it's 2022.

50:07 Just install them all.

50:08 Let it have it.

50:09 Yep.

50:10 One other thing that if you're in Python, I would strongly recommend you include would

50:13 be a pip install Playwright pytest, which is the pytest plugin for Playwright.

50:18 Again, plop, plop, plop, plop.

50:21 The Playwright package alone is going to be the browser automation tool.

50:25 The pytest plugin for Playwright is what gives you all the tie-ins to pytest so you can make

50:32 really nice tests.

50:34 It gives you the command line options like the headed option or the video option.

50:40 It gives you the fixtures for getting the context and the page.

50:43 So if you're going to be using it for testing, definitely Python, Playwright, plus pytest.

50:48 Amazing combo.

50:50 Cool.

50:50 If you're just doing pure automation, maybe you don't need the pytest plugins and so on.

50:57 Yeah, cool.

50:57 Okay.

50:57 So we've installed it.

50:59 And then immediately what might catch your eye is when I import, I import Playwright.either

51:07 sync API or async API.

51:09 And you're like, oh, wait, there's two APIs.

51:12 How lovely.

51:12 But maybe talk us through what the code, keep in mind this audio, but give us a sense of

51:17 what does it feel like to write code for the sync API?

51:19 And then we can see how it changes with async.

51:21 Sure, sure.

51:21 So with the sync API, of course, everything is step by step.

51:25 It waits before it goes on to the next thing.

51:26 I would say if you're doing test automation in Python, the sync API is the way to go.

51:31 And in fact, that pytest fixture I mentioned gives you everything sync.

51:35 You would use async if you're doing more just rogue automation.

51:39 You know, you're trying to sign up for your college courses.

51:42 That would be what you would use the async.

51:44 So in this little snippet, what it's doing here is with sync API, you're saying browser

51:50 equals p chromium launch.

51:52 That's opening up a chromium browser instance for Playwright.

51:56 So that's the full browser.

51:58 That's the start of the browser process.

51:59 Then off of that, the next line, page equals browser.newpage.

52:03 What it's saying there is from that browser instance, create a under the hood.

52:09 This is not included here, but create a new browser context.

52:12 And from that browser context, create a new page and give me the page options.

52:17 All of the interactions in Playwright are going to be going off of that page.

52:21 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.

52:27 So following that, the next line is the first call we see page.go to, you know, some web address,

52:33 http colon slash /playwright.dev.

52:36 So that would be an example of a browser interaction on the page.

52:40 That one, because that will load the webpage, it's directly off the page.

52:45 A lot of times you might need to say page.locator with your CSS selector, expat ID to identify an element on the page

52:53 and then do something on the element.

52:54 So you would say page.locator, blah, blah, blah, dot click.

52:57 Page.locator.fill with certain text.

53:01 That would be like typing text.

53:02 Right, okay.

53:02 Then the next line we see here.

53:04 Nice, then you can access like properties like page.title, right?

53:06 Oh yeah, you can get page title, you can get page URL.

53:09 I don't know the exact names of everything, but if you're using like Visual Studio Code

53:14 and Python typing, then you can get on a complete and find the whole list.

53:18 Beautiful.

53:18 Yeah, yeah, that's awesome.

53:20 So another thing it seems like I could do here is we've got p.chromium, p.webkit, I presume, and so on.

53:26 I could use a parameterized pytest test and give it the browser for Chromium.

53:33 Okay, so.

53:35 No?

53:35 So, okay.

53:36 How do I just test all the browsers?

53:38 Two things here.

53:38 Two things here.

53:39 First of all, what you just recommended is an antipatter.

53:42 You never want to use pytest parameters to choose browser.

53:44 Browser is a browser choice.

53:47 Browser choice is a test control input.

53:49 That's something that you want the user to specify, I want to target this browser.

53:52 And the way you would want to treat that is to say, okay, I have my whole test suite.

53:56 Honestly, all web UI tests should be able to run against any browser.

54:00 There's no reason one would test on Chromium versus Firefox or something.

54:03 So, you would want to say, hey, for this entire test run of these tests that I'm filtering on my suite, target Chromium.

54:11 If you wanted to test on Firefox, you spin up another process and say, okay, run these and target Firefox.

54:15 Test control input passed in and handle.

54:18 Now you're probably thinking, oh, okay, so now I can use a pytest fixture to read an environment variable and pass it in that way.

54:24 That's what the Playwright pytest plugin does for you.

54:27 Okay, nice.

54:29 Yeah, we'll get to that in a second.

54:30 Yeah, yeah.

54:30 That's another reason to use the plugin is because literally it's a command line option.

54:34 You know, project Chromium, project Firefox.

54:38 Or you can specify all of them and run three at a time.

54:40 Got it.

54:40 Okay, cool.

54:41 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, right?

54:51 Instead of with sync playwright SP, we have, we create an async with block to create an async playwright.

54:57 And then we await launching the browser or launching the process and then await getting the page.

55:02 And there's a lot of await on this page, honestly.

55:04 This might be the most await dense async thing I've ever seen in my life.

55:08 Oh, you should see the JavaScript code.

55:09 Which is not necessarily negative, but this is all await.

55:11 Like six lines of await.

55:12 Yeah, no, you're absolutely right.

55:14 In fact, right before our chat today, I was doing playwright in TypeScript.

55:18 And yeah, it's await, await, await, await, await, all the way down.

55:22 At least in Python, you get to choose.

55:24 Yeah, true.

55:25 Yeah, JavaScript doesn't have the sync options.

55:28 Yeah, so, but otherwise it's the same, right?

55:30 Exactly.

55:31 So when would I use, like when would, let me rephrase this.

55:33 When would you use the async API?

55:35 I would use the async API if I'm trying to do some sort of browser automation apart from test automation.

55:43 Like if I'm trying to write a tool that's trying to log in and register for college course,

55:48 or I'm trying to scrape numbers off of a dashboard on a website that change every five minutes or something.

55:55 That would be the case where I would probably write like a pyscript and just puke everything in one file.

56:00 And I would use the async API.

56:02 I would use sync API for test automation.

56:04 Got it.

56:04 Okay.

56:05 Would it make sense to use the async API if I was trying to run on all three browsers at once?

56:09 I mean, yeah.

56:10 Why would it still not go async there?

56:12 Well.

56:12 Maybe like an xdist or something like that on my PY test?

56:16 That would not be the appropriate way to handle that.

56:18 What you would do is you would code your test and it would be generic enough to run on any browser.

56:23 And then when you would launch it using the PY test plugin, you would specify all three browsers to run at the same time, which would basically triple the test.

56:33 And then you would use PY test xdist dash three.

56:36 So it would parallelize that.

56:38 Right.

56:38 So you would write the test as if it's generic and then you would use control options to parallelize and cross browser tests.

56:44 Yeah.

56:45 Probably the xdist anyway.

56:46 I don't know.

56:47 You probably know.

56:48 It's probably multi-process, not threaded anyway, right?

56:51 Yes.

56:51 Yeah.

56:52 So it doesn't really matter if it's asynchronous.

56:53 Correct.

56:54 Okay.

56:54 Got it.

56:55 Got it.

56:55 Got it.

56:55 And then here's the example of like how you might launch it in headed or not headed mode.

57:00 You would say like Firefox dot launch headless equals false.

57:04 There's another interesting parameter here.

57:06 Slow mo.

57:07 Mm-hmm.

57:08 Mm-hmm.

57:08 Like don't you want your test to be fast?

57:10 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.

57:17 Playwright is so fast that sometimes you can't track what's going on.

57:20 I kid you not.

57:21 It's fast.

57:23 And so what you would want to do during like your local development or debugging, you might want to inject a slowdown after every interaction.

57:31 Usually I use like 1,000 or 2,000 milliseconds just to kind of.

57:35 Yeah.

57:35 Also, I would recommend just like with headless option, slow-mo option, you can use the command line.

57:41 And I would even say that's the preferred way rather than injecting directly to code.

57:45 Yeah.

57:45 Probably also just to be nice.

57:47 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 you.

57:55 Yeah, because some websites will identify you as a bot and be like, nope, I'm rejecting your request.

58:00 So if you inject a slow-mo, you seem more like a human.

58:03 You'll skirt under the radar.

58:05 Ooh, I didn't even think of that, but that's right.

58:07 Yeah.

58:08 I'm sure that that actually, it may not be the intent.

58:10 The intent is to make it human interactable, but it's still, it might be necessary.

58:16 Get in that college course, get that 10 a.m. class, don't get banned.

58:20 Okay.

58:20 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.

58:28 But it was glorious.

58:29 I had the best class schedule of the year that year.

58:31 Nice.

58:32 Okay, so another thing you could do is you can record scripts using Playwright, CodeGen, and then give it a URL.

58:38 And then it'll watch you interact with it and then generate Python, try to mimic those interactions, right?

58:44 Mm-hmm.

58:44 Okay, that's pretty awesome.

58:46 We talked a lot about, we'll come back to the pytest in a second.

58:49 There's also a REPL mode, which is pretty, I mean, I guess that's just saying like you can call Python code in a REPL.

58:55 That's not super interesting.

58:57 If you're coming to Python from another ecosystem, this might be a big deal for you.

59:02 I think for us, we're like, oh yeah, you can do any Python in a REPL.

59:05 No, it's simple, whatever.

59:06 So somebody come from like the Java world, oh my gosh, this will blow their mind, you know, probably.

59:10 Yeah, that's for sure.

59:11 I guess I'd never really thought about creating an async REPL, but you can create an async REPL using Python-M asyncio and then you get a REPL, but it lets you write await.

59:21 I've never done that.

59:23 So I guess I learned something.

59:24 Then also it has this interesting way to build itself into a standalone executable.

59:31 So you don't need Python or anything else to run it using PyInstaller, but there's some integrated commands.

59:37 Tell us about this.

59:38 Like 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?

59:46 If you wanted to build your college course hacker scheduler thing, you could build it.

59:52 I see.

59:52 And then.

59:52 Yep.

59:52 You could build into it an executable and then it's a little easier to run.

59:55 That's all.

59:56 I see.

59:56 Then you tell it, it takes these command line arguments and then it goes and it.

01:00:00 Yep.

01:00:00 Okay.

01:00:00 Got it.

01:00:01 If I want to share it.

01:00:01 Sure.

01:00:01 By the way, the instructions on the website, people are watching.

01:00:04 There's a bash, a PowerShell and a batch version.

01:00:06 The bash version like doesn't have backslash ends or something.

01:00:09 I don't know.

01:00:10 It's a little weird.

01:00:10 Just look at the other ones.

01:00:12 So realize that's three lines.

01:00:13 Oops.

01:00:14 Oops.

01:00:15 All right.

01:00:16 It does have some interesting ideas.

01:00:18 You talked about the waiting and it says, don't use time.sleep.

01:00:22 You might be able to get away with async.io.sleep, but don't use time.sleep.

01:00:25 Use page.wait for timeout instead, which is interesting.

01:00:30 Apparently the time.sleep messes with its internal asynchronous.

01:00:34 Interesting.

01:00:34 Or something.

01:00:35 So yeah, just people be aware of that.

01:00:38 All right.

01:00:38 Let's talk pytest plugin real quick.

01:00:39 Sure.

01:00:40 Sure.

01:00:40 So we could write a pytest test that takes a page object, which is.

01:00:46 The browser process is launched.

01:00:48 A session is created and a page has been created and then it's handed to you.

01:00:52 Exactly.

01:00:53 So like that opening code snippet we just talked about, you don't need to do that when you're

01:00:57 doing pytest with the plugin.

01:00:59 You basically say, I want to use a page.

01:01:01 Fixture go.

01:01:02 Boom.

01:01:02 And it gives it to you.

01:01:03 So you can immediately jump into things like page go to, page locator, give me this, page

01:01:08 title, page click, you know, straight from the test function, which is really, really

01:01:13 nice.

01:01:14 It cuts down on all that boilerplate.

01:01:15 Yeah.

01:01:15 That's, that's very neat.

01:01:16 And then here, right below that in the, it shows the CLI options, pytest --headed,

01:01:23 --browser, Firefox or multiple browsers and so on.

01:01:26 Mm-hmm.

01:01:27 Mm-hmm.

01:01:27 Yeah.

01:01:28 Very nice.

01:01:29 Very nice.

01:01:29 What else should we talk about?

01:01:30 Maybe we could talk like text input and stuff just really quick, because I feel like that

01:01:35 goes a little bit beyond just CSS selectors, like the clicks and the inputs and the.

01:01:39 Sure, sure, sure.

01:01:40 So on.

01:01:40 So which one do we talk about?

01:01:42 Inputs, locators?

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

01:01:47 There you go.

01:01:47 So the selectors are the starting point of finding things on the page.

01:01:53 You can identify elements on the page from many different kinds of selectors.

01:01:56 You can have an ID, boom, you nail it, you know, assuming it's your unique on the page,

01:02:01 right?

01:02:02 You can use a CSS selector.

01:02:03 You can use an XPath.

01:02:05 All those are things that are also selectors available with Selenium WebDriver and Cypress.

01:02:10 But Playwright has a few other kinds of selectors that it supports.

01:02:14 One of the most helpful ones is what they call a text selector.

01:02:17 Oh, you've got it on the screen here.

01:02:18 Yeah, there you go.

01:02:18 So like I want the button that says login.

01:02:21 Correct.

01:02:22 Exactly.

01:02:23 Because I don't care what kind of element it is.

01:02:26 I just want the element that has a text that says login, that has submit.

01:02:31 As long as it's the only one on the page, you're going to get a right.

01:02:34 That lends to the developer experience, right?

01:02:37 Because you're trying to figure out CSS selectors and XPaths.

01:02:41 There's a cognitive load.

01:02:42 Sometimes you have to do it.

01:02:43 But if you don't have to and you can do something easier, it's better for you and for the test

01:02:47 case.

01:02:48 Simple is better than complex.

01:02:49 And so here, right, yeah.

01:02:51 Give me the text.

01:02:51 Boom, I'll find the element.

01:02:52 So that's one of the really, really cool selectors.

01:02:55 Yeah, that's fantastic.

01:02:56 And then you can come in here for input and like go and say, I would like to check the check

01:03:02 box that has the ID agree.

01:03:04 Or that has the text XL.

01:03:06 Like what size of t-shirt do you want?

01:03:08 I want XL.

01:03:08 Check that.

01:03:09 That radio button or that check box.

01:03:11 That's super cool.

01:03:12 Actually, I should comment that the commands we're seeing here are things like page check,

01:03:16 page uncheck, page fill.

01:03:18 That's actually no longer the recommended practice with Playwright.

01:03:21 You can do it this way.

01:03:23 What do they suggest?

01:03:23 What they suggest is page.locator, pop in your selector, and then dot whatever the interaction

01:03:29 is.

01:03:30 So in these cases, instead of page dot check, agree will be page locator agree dot check.

01:03:35 And the reason they recommend that, even though it's more verbose, it's ultimately supposed

01:03:41 to lead you to a refactoring into things like page objects, right?

01:03:44 Because you are separating the concern of page structure from interaction.

01:03:48 Whereas when they're together, even though it's more concise, it is readable.

01:03:52 You're combining those concerns.

01:03:54 It doesn't really matter.

01:03:56 You can use both ways.

01:03:57 Sure.

01:03:58 Okay.

01:03:59 Yeah.

01:03:59 These are nice.

01:04:00 All right.

01:04:01 So really, basically the takeaway, like for example, here I can go and find me the button

01:04:07 that says text submit, and then I can do a hover over it and then click, which I think

01:04:10 is interesting because often it doesn't matter.

01:04:13 But sometimes if you hover over a thing, it exposes different DOM elements that when you

01:04:18 click on them may have a different behavior.

01:04:19 Indeed.

01:04:20 So you have this really fine grain control.

01:04:21 Indeed.

01:04:22 Got a few.

01:04:23 Go.

01:04:23 No.

01:04:23 Okay.

01:04:23 Finish your thought.

01:04:24 Sorry.

01:04:24 Sorry.

01:04:24 I was going to say like, also in that example, we just showed you created the locator object

01:04:29 to one time, and then you perform multiple interactions on it.

01:04:32 Whereas if we, if you had repeated or if you had combined the calls, you would have under

01:04:37 the hood duplicated the creation of the same locator object.

01:04:40 So there's a sense of reusability there as well.

01:04:43 That's all.

01:04:43 Got it.

01:04:43 All right.

01:04:44 Let's round out our conversation here just quickly with the tools.

01:04:48 So I think that these are really nice.

01:04:50 These visual tools here.

01:04:51 All right.

01:04:51 The first one I pulled up first is the playwright inspector, and it's kind of like, I don't

01:04:56 even know how to describe it.

01:04:57 So it's, it's as if you went through and you did a bunch of CSS stuff and then playwright

01:05:02 wrote asynchronous Python code with the things like page.click and whatnot that we discussed.

01:05:08 And then, then you can go and check it out.

01:05:10 So this is kind of like a playback understanding type thing, right?

01:05:15 Yeah.

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 did.

01:05:19 Here's more information on it.

01:05:21 Very similar to Chrome dev tools.

01:05:24 I will caveat to say, I have not used this much myself.

01:05:27 This is also kind of new to me too.

01:05:29 Also on top of that, I should say the playwright team keeps pumping out new, awesome stuff all

01:05:33 the time.

01:05:33 So hold on to your butts.

01:05:35 They just keep making more awesome, cool stuff.

01:05:37 Yeah.

01:05:37 Apparently it has features for like debugging selectors for stepping through like one of

01:05:42 these playback scripts to see how it goes and so on.

01:05:44 It's really cool.

01:05:45 Real time stuff here.

01:05:47 Yeah.

01:05:47 Yeah.

01:05:47 This is super neat.

01:05:48 Okay.

01:05:48 Another one, the trace viewer.

01:05:50 This, like I said, looks a little bit, it's a little bit like the dev tools of a browser.

01:05:54 If you open up the network tab and then select, show me the response in that view for people

01:06:00 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.

01:06:04 And it bundles up like so many things.

01:06:07 Like I think you can say like, oh, I want to capture the screenshots.

01:06:10 I want to capture the video.

01:06:12 I want to capture the DOMS of the pages.

01:06:13 I want the stores.

01:06:14 Like it all ended up like, I think it bundles it up all for you in one artifact.

01:06:18 It's like, you're just tested done.

01:06:19 Here you go.

01:06:20 Have fun looking at it.

01:06:21 So it's the kind of thing where you could, when you, let's say you're running this in continuous

01:06:25 integration, you know, test fail, it bundles all this stuff up, saves it for you as an artifact

01:06:30 and then you can go look at it later for the ones that fail and be like, oh, so here's

01:06:34 all the context of what went wrong.

01:06:36 And you can really get in there and figure out what happened.

01:06:38 It's fantastic.

01:06:40 It has all the actions.

01:06:41 You click on them and it says, what was the action?

01:06:43 What was it like before?

01:06:44 What was it like after?

01:06:45 What did the network do?

01:06:46 Yeah.

01:06:46 Really good.

01:06:47 And then test generation because, hey, we don't need to write tests.

01:06:50 We'll just tell it to go.

01:06:51 No, I'm just kidding.

01:06:52 Tell us about this.

01:06:53 This is pretty cool though.

01:06:54 This is like fire up the browser.

01:06:56 Let me interact with it and then generate a script that I can go from there.

01:07:00 Yeah.

01:07:00 Basically it's like a screen recorder.

01:07:01 Yeah.

01:07:02 You start the recorder, you navigate through the webpage, you know, you do your workflow,

01:07:06 you stop the recorder and then it turns all of the things that you did into a Playbride.

01:07:11 Right.

01:07:11 Instead of recording video, it records asynchronous Python.

01:07:14 Basically.

01:07:16 So that it generates.

01:07:17 Now this is really cool and it's super easy.

01:07:19 The other thing that's worth noting here is they talk about authenticated state.

01:07:24 So if you've got to log in and set up some cookies and local storage, you know, like even if you've

01:07:28 got a JavaScript app that needs to read and write stuff to local storage, you can sort

01:07:33 of save and load that from a JavaScript, the JSON file rather.

01:07:36 Yeah.

01:07:36 So because that's another thing, particularly with test automation, how many times you have

01:07:40 to log into your app under test, username, password, token or whatever.

01:07:44 And so, I mean, you can do this with pretty much any browser automation tool.

01:07:48 This is how Playbride does it.

01:07:49 You're basically caching that authentication so that you can reuse it for different sessions

01:07:55 or tests.

01:07:55 So you don't have to burn that five seconds of log in every single time.

01:07:59 Sure.

01:08:00 If you're not trying to test the log in flow, it's just in your way.

01:08:03 Correct.

01:08:03 Yeah.

01:08:03 Fantastic.

01:08:04 I guess debugging tools.

01:08:05 We could look real quick.

01:08:06 I mean, I feel like we kind of touched a lot of them.

01:08:08 Anything else you want to highlight?

01:08:09 Maybe running in debug mode?

01:08:11 I mean, it's all goodness.

01:08:14 I would say go read the docs up on it.

01:08:15 There's more than we can cover in a one hour discussion.

01:08:17 Yeah.

01:08:18 Well, I think we're down to minutes, not hours.

01:08:20 So maybe leave it there.

01:08:23 There's a bunch of guides about like auto-weighting, testing APIs, browser context, JavaScript events.

01:08:28 Like there's a lot of stuff to go in here.

01:08:31 And I'll check out even testing video.

01:08:33 We're recording videos.

01:08:34 Yeah.

01:08:35 Cool.

01:08:35 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.

01:08:44 It's on my GitHub account.

01:08:46 It's playwright-python-tutorial.

01:08:49 I have given this at PyCon.

01:08:51 I gave this at Python Web Conference.

01:08:53 I think I gave this at the TAU Homecoming last year.

01:08:56 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.

01:09:04 And it walks you through in glorious detail all the way.

01:09:07 If this is something you want to get hands-on with, yep, there it is.

01:09:11 Boom.

01:09:11 Give that a try.

01:09:12 Check it out.

01:09:13 Follow the instructions in the tutorial folder.

01:09:15 And let me know if you get stuck.

01:09:17 Yeah, this is really great.

01:09:17 People can follow along and play with it, right?

01:09:20 Do a little DuckDuckGo.

01:09:21 Basically.

01:09:22 Yeah.

01:09:23 No, but take some other public website like DuckDuckGo and figure out how you might go about testing it, right?

01:09:29 Work your way through understanding what you should do to test it and then put that into action with Playwright.

01:09:34 Yep.

01:09:34 Yep.

01:09:35 All right.

01:09:35 Well, I think that pretty much is the time we've had to talk about this.

01:09:40 Anything else you want to quickly touch on before we call it a wrap?

01:09:43 No.

01:09:43 I mean, have fun with it.

01:09:45 I think Playwright is awesome.

01:09:46 I really love what the team is doing.

01:09:47 And if you ever have, if anyone ever has questions, all testing, automation, Playwright, Selenium, you name it, hit me up on Twitter, AutomationPanda.

01:09:55 Right on.

01:09:56 All right.