00:00:00 Kent: Hey everybody, welcome. This is my friend Debbie. Say hi Debbie.

00:00:04 Debbie: Hi everyone.

00:00:06 Kent: So Debbie O'Brien is, you live in Spain, right?

00:00:10 Debbie: Mallorca, yes.

00:00:11 Kent: Mallorca, yes. So Debbie lives in Spain. I met Debbie in person. I think the first time we met in person was in Croatia last year, where we went swimming together in the Mediterranean, which was fun. And actually, like, you pushed me, not like physically pushed me, but like you pushed me beyond what I normally

00:00:31 would have done. Like normally when I go traveling and I'm by a big body of water, I like to jump in just to say, I have been in the Pacific Ocean or I've been, you know, wherever. And you like actually started swimming out And I'm like, Oh, okay, I guess we're gonna, we're gonna swim out there a little ways. And, and, it was actually really refreshing. It was

00:00:51 Debbie: so nice.

00:00:52 Kent: Yeah, it was really great. And like that, the, conference in Croatia is called Infobip Shift and it's just really great conference. Are you going again this year? That's like coming up.

00:01:03 Debbie: No, unfortunately not, but it is a great conference. And so diversity as well.

00:01:08 Kent: Yeah, a hundred percent. I love that conference. That was my second time there. And I would like to go this year, but it's yeah, Just challenging.

00:01:16 Debbie: We'll go next year and go for a swim again.

00:01:18 Kent: Yes, yes, let's do it. Okay, so Debbie works at Microsoft on the Playwright team. So, Debbie, can you give us an intro to yourself? You can be as personal or professional as you like.

00:01:30 Debbie: Oh, gosh. Yeah, so basically I work at Microsoft advocating for Playwright. So my job is to try and build the Playwright community, make sure that everyone out there knows how to use it, is comfortable using it, and listen to the feedback of those users and take that on board and bring it back to the engineers so they can create a better product for our users. And it's a really cool

00:01:50 job because it's open source and I've always been working in open source for the last 4 years. So to get to work with open source again, and also testing is something I've been passionate about. I've been forcing companies to do testing for many years when I worked, you know, in the agencies and stuff. So it's like so nice to kind of say, yes, come on, testing everyone. Come on, let's, let's get testing.

00:02:10 Kent: That is awesome. Yeah. And you know, you've done such a marvelous job since you joined the team. I feel like Playwright has been very thoughtful of users. And so you've just done a really good job of that. I especially appreciated being involved in the new locators API.

00:02:31 That just, that changed everything for me, honestly. I was really into Cypress, and Cypress is still a great tool. There are people who even prefer it over Playwright, and that's fine, that's great. But Once the locators were added that resemble the testing library locators, then that

00:02:51 was a huge plus for me. And then you came in and made the UI mode. And I was like, I don't know why I would use Cypress anymore. Like this is just so good. So yeah, do you wanna talk about some of the process for making some of those changes?

00:03:07 Debbie: Well, I will say I remember in the conference in Croatia where we sat down and you said, right, okay, show me Playwright. And I watched you use it and I watched you struggle with certain things. And that was 1 of the things you struggled with, right? It was like, why can I not get testing library, these roles and things like that? So just watching how you're trying to do stuff

00:03:28 is like, oh, this is how Kent or any other user is probably trying to use Playwright.

00:03:32 Kent: And how

00:03:33 Debbie: can we then, and that basically took back to the team and said, right, this is what Ken's trying to do. How can we improve on this? And then obviously the engineers come up with their magic and put things to great work, right?

00:03:45 Kent: Yes, yes. Actually, that is a testament for conferences, right? It's like, it's only at an in-person conference do you have that type of an experience where it's like, let's sit down together and we can see each other and like body language and all of that just feels so natural. And I remember that very well too because there were a number of things

00:04:05 that you surprised me and I'm like, whoa, it can do that. Like that's very cool.

00:04:08 Debbie: Like the default web server, you're like installing a package and I just like, I'll go to wait, I'm gonna watch, I'll watch. And then like, Why don't you just use the config file and just uncomment? Oh my God, this is already built in.

00:04:19 Kent: Yes, yes, yes. I really, I like that feature a lot as well. So, yeah, the folks who are going through the workshops will be using Playwright. I'm not going to be showing them how to configure Playwright because I've tried it before and configuration

00:04:39 exercises are the most boring thing I can imagine because it's literally just like, here are the docs and now configure this. The main thing is it's not that it's boring, it's that it's information that you don't use on a regular basis.

00:04:55 Debbie: So it's just like, yeah. Yeah, like everything is pretty much set up for you. So we try to kind of think like, except for like the base URL that you might add in or adding the web server, everything else just works and it's just like, you know, it just works, just as a job.

00:05:07 Kent: Yeah, yeah, precisely. So people will, when they start with the Playwright tests in the workshop, everything is configured and set up for them and they're just working in test files, which is where they're going to work on day to day. And so where we start is an unauthenticated test just to make sure that that works.

00:05:27 But we get into like going through login experience and...

00:05:32 Debbie: You start with the most complicated thing. Oh my God.

00:05:34 Kent: Yes. Yep, yep. We very early, we get into, okay, now let's test the login stuff. And then we add utilities for being logged in. So I want to talk about briefly, like what is the best way in your mind to test the logged in

00:05:54 experience? Because most of us are building, the primary number of our features are the logged in experience. And I've seen a lot of people have a little utility that is like basically their login test and they run their login test before they run the rest of their

00:06:14 logged in state tests. So can you talk a little bit about that approach and why it may not be the best?

00:06:21 Debbie: Well, it depends, right? Because have you used project dependencies?

00:06:25 Kent: Oh, no, I haven't heard of this.

00:06:27 Debbie: I see, okay. So we have project dependencies, which basically means you can have your login test as a project, right? So this is the, this test which logs in can then be used as a, like a setup, right? So it's kind of like a global setup, but it's called, we used project dependencies. So In your config file,

00:06:47 and you do have to go into the config file, and you add in this login test. Then you basically go to the next test, which could be user profile or whatever, and the user profile will depend on the login test. That login test will run every time that user profile test runs. But maybe the, I don't know, navigation

00:07:08 test doesn't need the login. So it's not going to run that time. So you basically say which test depends on which, and you can kind of run those tests and it's really, really cool. What's in LIMO

00:07:18 Kent: 2? Yeah, okay, so that, huh, yeah, that's very interesting. I think I still would prefer the mechanism we're doing in the workshop, so that's good. I mean, that I don't have to change everything now. But, and the reason I would prefer it is just because it feels unnecessary, unnecessary because we already have some

00:07:39 confirmation that login works and that like just adds, you know, 3 seconds to every test to go through that flow. But I can totally see that feature.

00:07:47 Debbie: You can use load load storage so you can state load the state, so that means it doesn't rerun that test. It's going to save that storage.

00:07:58 Kent: Holy smokes, really?

00:08:00 Debbie: Yeah, that is watching our release videos.

00:08:04 Kent: Oh no, I just revealed my lack of engagement. Oh dear. That is very cool. So 1 of the big challenges with login in particular is, especially when I was working at PayPal, this was a big challenge. I wanted to do some login test stuff and I had no

00:08:24 idea how the auth worked at PayPal. It's this huge company, there are like 30 cookies, okay, maybe not 30, But there are like a number of cookies and I didn't know which ones were really relevant to the login and like what they even did. They always like cryptic weird stuff. And so it took me a long time to figure out. But if I had that feature, I could just say,

00:08:45 run this test and then save the state. And then that can be the starting for these others.

00:08:50 Debbie: Exactly. And then it's quicker. And also if like your login breaks, it's not gonna run those other tests, right? Because it's, it depends on it. So those tests don't ever get run if something in your login is not working.

00:09:01 Kent: Oh my word. I have so much other cool things that I can teach now.

00:09:05 Debbie: Yeah.

00:09:06 Kent: That is amazing. Yeah, that's such a great idea. Holy smokes. So, all right, I wanna hear about other things that you've noticed people don't know that they should.

00:09:18 Debbie: Okay, well, 1 I kind of learned myself the other day was sharding, which is something like, I thought was super complicated and super like, sounds scary, you know? And sharding is basically about splitting your test across multiple machines. Now, all of a sudden you've lost me. I'm like, what do you mean? But basically, my personal website, I've got

00:09:38 about 200 tests because I run it on 3 browsers. Some of them are just like testing simple things, but It takes time, it takes half an hour, which is a long time when you're trying to fix something really quickly. Then the test fails, you're like, oh my God, I got to run again. But we can use sharding on say GitHub using GitHub Actions, and it's really

00:09:58 simple to do. You can say, I want to shard that test and just say 4 shards. It's going to run, divide it by 4 basically, and I get my test down to 7 minutes instead of 30 minutes. That's a massive difference. It's easy to set up. It's just change something in the GitHub Actions file and a little bit in the configuration.

00:10:20 Again, it was in our last release video, and it's in the docs, and we'll have some blog posts and videos as well coming out soon. But that's really cool that I didn't know about, and I'm sure other users don't know about.

00:10:31 Kent: Yeah, yeah, that is very cool. So I guess that really depends on your CI infrastructure and whether you have the machines available and how to communicate with those machines and stuff. But it sounds like you have it working with GitHub Actions. You'll have examples of how to make that work.

00:10:47 Debbie: You can just go to my website and check it out. You can see all my failed attempts as well. And then you can see it. Yeah.

00:10:53 Kent: Oh, the pain is real. I totally can feel that. Yes. That's really awesome. Okay. Yeah, that's actually a great feature. And it makes me think of something else I wanted to discuss, and that is, when is Playwright the right fix? Because 1 of the things that we're, or the right tool, because 1 of the things that we're

00:11:13 doing in the workshop is we're not just doing end-to-end tests, we're also doing low-level unit tests on function, and then we're doing component tests on a component, and then route tests on a route, and all of those are running inside of VTest. And actually we also have like API tests that are running

00:11:34 inside of V-Test as well. And so in my experience, I have found the most success using Playwright just for my end-to-end tests and then V-Test for everything else. But I know that Playwright does support component testing. So I'd like to talk a little bit about where you see

00:11:55 the different tools and what is most appropriate for what kind of test.

00:12:00 Debbie: I think component testing is something that's kind of still very new in a lot of people's workflow. So it's like they're still going from unit and building end-to-end tests and the component is kind of in the middle, right? And it's a really useful test, especially if you're building a component library or something that's going to be shared across multiple websites. But if you're just testing maybe 1 website, maybe

00:12:20 component test is maybe too much, maybe it's not. That's a decision you need to make within your scope of your project. We do have support for component testing. It is still like experimental. We call it because we don't feel that there's enough people using it for us to get enough feedback to be able to say this is yes exactly what you need and what you want

00:12:40 because the use is not there. We're not seeing so many people on board as much as like the end-to-end tests. We do have API testing as well, and a lot of people are using that. So it just depends, but it depends on how much of your API you want to test. Do we cover all the features that you want? I don't know. That depends

00:13:00 on what you want to test. But basically, yeah, end-to-end testing is our main focus for sure. And I think people are switching from doing less unit tests and more end-to-end tests. I think That's the biggest shift we're seeing in everything, and that's where Playwright really fits into your workflow. And if you've

00:13:20 done a unit test or testing library, you go to Playwright, you'd feel at home, right?

00:13:25 Kent: 100%, yeah. Yeah, actually that resembles very much my personal experience as well. I'll tell people that the testing trophy, which is the shape of how I think about where you focus your test, the testing trophy is getting a little top heavy for me. So not in a bad way, like in a good way. That's just like, I'm feeling myself

00:13:46 wanting to do more end-to-end tests than I have in the past, because the tools in that realm are getting much better, which is a great thing. So to dive into the component testing a little bit more, I can tell you from my own experience, the primary reason I'm not using or teaching component testing

00:14:06 with Playwright quite yet is because it's experimental and I experimented with it. And there are a couple interesting limitations that once lifted, I think I'll be more likely to use. But the primary thing that I have noticed is that

00:14:26 it seems that Playwright is gonna be responsible for compiling my code to get it into a state where it can be tested. And yeah, yeah, it uses Vite, yep. Which is gonna be potentially different from the way that I'm building my code for production, which always kind of makes me feel funny

00:14:47 when those 2 things are going to be different. So if there is some way to get Playwright to let me be in charge of the build,

00:14:54 Debbie: that's interesting. That could help. I want to render this in. Yeah. Yeah.

00:15:00 Kent: Yeah. So, okay, there was another thing that you mentioned as you were talking that, oh, there actually, so another thing that we don't get into in the course, but would be interesting to talk about is VTest it actually has experimental in browser support using Playwright

00:15:20 and WebDriver and I think there's another that it supports. And I tried that, it didn't quite work for me yet. But yeah, Playwright is seeming to become the foundation for a lot of automation tools for automating the browser. Are there other uses of Playwright that you're seeing outside

00:15:40 of using it as it's the end to end test runner?

00:15:47 Debbie: I mean, there's a lot of use cases for it, for sure. Some people are using visual testing as well, right? And then some people are going into scraping, like, scraping sounds horrible, automating things, right? So there's a lot of use cases, but obviously there's a big difference, right? So previously Playwright was like a library. And when people

00:16:07 started to using it in the, you know, 3 years ago when it first came out. But because the focus has gone on the test runner, all the features are in the test runner, which means all that auto-weighting, that retryability, having less flaky tests, comes with that test runner. So those who are using the library and building upon it, they have some limitations. So it depends on what they're doing with it. And we're

00:16:27 seeing a lot of, like, you know, frameworks are building on top of others are building on top of it. But it's about really make sure you're actually using Playwright to the way Playwright should be used. That's our only concern when it comes to the integrations that are out there, because are they really showing off Playwright's coolest and best features?

00:16:45 Kent: Yeah, yeah. Well, I definitely like using Playwright as it is. So that's good. Well, 1 of the major drawbacks of using VTest is that the like in the typical way is that it's running in node and we're trying to, and for some things like our API that we're hitting

00:17:06 for that test or for our pure functions and stuff like that, like that's fine. But as soon as you want to have a DOM for like testing some UI, that becomes a challenge because we have simulated DOMs with JS DOM or Happy DOM and they're not spec compliant entirely and

00:17:26 they miss a lot of features. And so that's why I'm very intrigued by having either, like I'm seeing both sides coming closer to each other. So V-Test is over here sitting in DOM and they're like, I kind of want to try and run in Playwright, but within V-Test. And then Playwright's over here saying, I kind of want to run your component

00:17:46 tests. Like I want to get lower down the testing trophy to cover those use cases. Which I find pretty interesting.

00:17:53 Debbie: Yeah. I mean, if we could do everything, it would be, it would be incredible. And we, we do, we do a lot as it is. But unit tests, we don't want to do unit tests because we testers do such a great job and there's like, you know, you can't focus on absolutely everything. So I think it's like, you have to draw the line and say like, this is what we're focusing on. Root interception, right. It's something as well that we can do, which is,

00:18:13 you know, you can, you can do, Like you can do a hell of a lot. So, basically it's more about, we don't want to go down all the way, although it might look like we are. But I think it's okay to have 2 tools to test your, your website. I don't think Playwright needs to be the, you only use Playwright and then you never use anything else. I don't think it has

00:18:33 to be that way. Maybe that's the future, who knows?

00:18:36 Kent: Yeah, yeah. I actually really appreciate that perspective, especially coming from you, that you don't have to be the 1 thing for everything. I think that a good line for Playwright to draw is we will do everything that you need to test that runs in a browser. And so for the Node stuff,

00:18:56 we can just stick with VTest. And I hope that in the future, the component testing gets even more solidified so that we can run any. So I would really like to drop JS DOM. That's what I'm saying.

00:19:09 Debbie: Okay. I see. I will bring that feedback back to the team and let's see in a couple of months where we're at.

00:19:14 Kent: Okay. Yeah. That sounds awesome. And I just love how much Microsoft is investing in Playwright to make it such a vital tool in our toolbox for testing.

00:19:25 Debbie: Well, we have so many apps within Microsoft that need to be tested, right? You know, Like from VS code to Bing, to everything that we're testing, everything. Teams is using it. Like, so there's so many of our products that need to be tested properly. So it makes sense for us to invest in something that Microsoft can use internally, but also that the whole

00:19:45 world can use it. Because if we just use it, we're not really getting that user feedback in a real world scenario. And it's when you do open source, you learn so much more than if you do a closed source product only related to what your company wants.

00:20:00 Kent: I a hundred percent agree. Yeah, that makes tons of sense. So 1 question that I get when I teach about testing is from people who are doing React Native or something like they're doing native development. My impression is that that's 1 area that Playwright has just decided we're not going to do native mobile

00:20:20 stuff. Is that correct or do you have any tools for mobile?

00:20:23 Debbie: I mean, I would say, well, we can test Android. It's an experimental with WebView and things like that, right? So you can test that out, but iOS is more complicated, of course. I would say like if, you know, somebody wanted to give us loads of money and give us a team that is mobile, you know,

00:20:44 based and knows their stuff and is able to invest in that, then we would happily do it. It's not that we don't want to, it's just that our team is actually really, really small. So it's really hard to do everything. And we could do everything and it would be really bad. Or we can do small amount, but make sure we do it good. And I think that's their key to success.

00:21:03 Kent: Very good. Yeah, that makes tons of sense. So if it runs in a browser, then it works in Playwright. And I think that's a pretty good line to draw. That's what it's for. It's for browser testing. Yeah, a hundred percent. And then of course, like there are tools within Playwright to change the viewport size. So if you wanna test the mobile

00:21:24 version

00:21:24 Debbie: of your site. Yeah, you can do mobile Safari and you can emulate that browser in a mobile, But it isn't an app, which is different sometimes to a mobile version. So that's, I mean, yeah, it'd be cool. Let's test mobiles. Let's test everything. But who knows future?

00:21:39 Kent: Yeah. Just, just be super good at the browser stuff. I, myself personally, I only care about the web anyway.

00:21:45 Debbie: So yeah, I don't do apps. I don't build apps. So I don't have the need to test them either.

00:21:51 Kent: Yeah. Yeah Well, cool. Is there anything that we haven't touched? I feel like we've gone in a lot of different directions with this Is there anything else that you want to talk about with Playwright or testing in general that we haven't touched on?

00:22:05 Debbie: Well, I would say with Playwright, and this is going to be direct especially to you, Kent, since you didn't watch our last videos. But I would say seriously watch our release videos because we do come out with, you know, new things. And we also try and teach people something that they can do or learn from in those videos. And they're only really short eight-minute videos. But also,

00:22:25 we update every month. There's a reason why we update, because we update the browsers to make sure you're testing on the latest version of the browsers. So really, we encourage you to update your Playwright version as often as possible. Sometimes you leave it there for 6 months and it's like, but then you're not getting everything that Playwright can give you and you're also not testing on

00:22:45 the most up-to-date browsers. So definitely keep your Playwright version up to date. I think that's like key to you being and doing, like you're testing better. And then when you're filing bugs, right? Cause sometimes people file a bug, it's like, what version are you on? Yeah, Of course that doesn't work, right? You don't fix the version. We'll fix it, right? So yeah. And then also file

00:23:05 issues and feature requests. So Kent, for example, what you just said to me there, that should be an issue. And you know, because you submitted issues and they got sorted and feature requests got done. People upvote them and we work with the upvotes of those issues. So if you have something that you want done, you're frustrated because something isn't working for you, let us know.

00:23:26 We can't read minds. We value people's coming to us and telling us how we can make Playwright better. So please submit issues, book reports, feature requests and upvote them.

00:23:38 Kent: Yeah, that's awesome, awesome tips. And I'll also add, join the Discord.

00:23:44 Debbie: Yes,

00:23:44 Kent: yes. I was really happy to see the discord when that was put together. So thank

00:23:49 Debbie: you I'm only gonna talk to you some discord like oh my god. We have to set up this good

00:23:56 Kent: Yeah, a lot of places so like prisma was also on Slack and I was like, listen guys and gals, I don't like Slack, could we move over to Discord? And I think enough people told them that, that they finally moved over to Discord too, which Discord's not perfect, but it sure is nice. And

00:24:16 so I'm

00:24:17 Debbie: glad that we did. It was like during my hit and that we lost all our messages after like a month and stuff. And then you can find anything. And it's like, why would you delete that? It's like, come on. Whereas Discord is quite hard to keep up with because we're so active. There's so many questions. There's so many things, but people are answering the questions for us which means we don't have to unless like someone tags us and we need to jump

00:24:37 in but it's so great because everyone's helping each other so discord has been a huge success for us.

00:24:42 Kent: Oh very good yeah so go join the discord and there's a playwright an ex account as well or twitter account.

00:24:50 Debbie: Is that what we call it now?

00:24:53 Kent: And then Debbie how do people keep up with you and what you're doing

00:24:57 Debbie: Yeah, I have a website Debbie codes and if you go to there you'll find all the links to me to everywhere. And most of my blog posts might be about testing, although some could be about running and other stuff and, personal stuff. But yeah, and videos, I'm doing a lot of playwright videos at the moment and courses, but they'll be on the Playwright YouTube channel. So check that out as well. But yeah,

00:25:17 Debbie.co, it's easy.

00:25:19 Kent: Awesome. Cool. Well, thank you so much, Debbie. It's always a pleasure to chat with you. I enjoy our conversations and look forward to the next time we see each other.

00:25:26 Debbie: Yes. We need to go for a swim, Kent.

00:25:30 Kent: Bye everybody. Bye. Bye everybody.

00:25:32 Debbie: Bye. Bye.