Paul:
Hi there and welcome to PodRocket. I'm your host Paul, and today we're joined with Debbie O'Brien, who is a senior program manager at Microsoft and she's coming to advocate for Playwright today. Welcome to the podcast, Debbie.

Debbie O'Brien:
Thank you very much, Paul. It's nice to be here. Yes, I'm here to talk about Playwright and hopefully get the whole world testing their applications.

Paul:
Yes, testing is important and we never do it, so anything to urge us in the direction of it.

Debbie O'Brien:
Yeah, why do we never do it? This is the whole thing. Why? What's going on in the world?

Paul:
And you know what's weird is when you build... I tried the whole test driven development thing once and I was like, whoa.

Debbie O'Brien:
No, that's really hard. I don't do that.

Paul:
I did it for a small little Flask project and I wrote out all my requirements and it was really great and that convinced me, wow, testing might be good. So yeah, why don't we do it? I don't know. But you're here to convince us that it's easier than we think and that there are really good tools out there and that we should get on it. Just to cut to the chase here, Playwright is an end to end testing framework, right?

Debbie O'Brien:
Correct. So the whole aim is to try and make you test your applications end to end so automated, because if you remember way back, people were writing all that... Testing on their own, so take out a form and fill out the whole form and then press send and see if it works and go, "Yes, it works, or it doesn't." And then go back and do it all over again, and that's a load of time wasted and we can automate that. So you write one test and then it's just going to fill all that in seconds, super fast, because computers are faster than us, and then send it. We know that's going to work. So we want to automate our tests. We want our tests to be easy. We want to make testing fun. And obviously Playwright is open source, which means it's free and that's very important as well because people want to use free tools and have a great community around it.

Paul:
I feel like we're getting to this really nice place in software now where it's like if you're not building with open source, you might want to rethink some of the... Not saying everybody can just build with open source, but lots of stacks now have open source everywhere. So it's really great to hear Playwright's open source. I think a lot of community members are going to latch onto that and it's going to be a real driving factor if it gets included in the stack or not.

Debbie O'Brien:
Yeah, because it's community driven, not driven by a corporation. Even though we're under Microsoft, it's community driven. So if you want something done, a new feature, you got to create an issue. And it doesn't matter where you work, it matters how many people up-vote that and basically want that, because we want to drive it where the community wants it to be driven. That's kind of what makes it really cool.

Paul:
So if somebody was listening to their podcast and say, "Wait, I do test driven develop... Or end to end development." I accidentally said test driven. "I do end to end development." Why should they look in Playwright? What's something, off the bat, that you love talking about that's just really easy to see how Playwright is different?

Debbie O'Brien:
There's so many things, but there's... Basically, one of the great things about Playwright is it works across many languages. So you are a JavaScript or TypeScript developer, you can write using that. You're a Python developer, you can raise using Python. You're a Java developer, you can write using Java. You're a .Net developer, you can write using .Net. And that's kind of really helpful because then you don't have to change your language to use Playwright, you can choose the language that best suits you.
And then you've got lots of other things like so much parallelism for free, that's just works out of the box. Test isolation. So Playwright creates a new browser context, which means all your tests, every single test, has this new context and you don't have to do any cleaning up between tests. So everything basically just... It's kind of starting up a new incognito window each time.

Paul:
It feels like that's a very functional approach where each test is its own thing, is its own universe.

Debbie O'Brien:
And it means when that test breaks, you don't have to go, "Did something happen in another test to cause that?" No, that test broke, that only test, whatever broke happened in that test and you can debug that much easier. So you got a lot less flakiness because of that. So test isolation is super important. And then there's other things like we have a generator to help generate code.
We have a trace viewer so you can go back in time and see what happened at each stage, better than a video. You can actually step by step, look at it and then inspect the DOM because it's a DOM snapshot. And it's so hard to say on a podcast because I can't show you anything visually, but it's really cool.

Paul:
Its funny you bring that up because I think at LogRocket there's some similar technology about understanding the DOM tree and then being able to retroactively go through all the events that happen in sort of a timeline and debug something, which I know has been an extremely powerful feature that customers have been like, "Wow." I find bugs I never even knew I could find. So having that where you can make your own test from the get go, I'm sure you can discover things about even the way you wrote the structure of the code, seeing it step through.

Debbie O'Brien:
Yeah you can actually write better code because as you're creating the selectors to write your tests, and then the test might break because there's a strict mode violation. You say, "Hey, I've got two things with the same class or the same name, let's create a better selector." And then you can use the pic selectors, you can start selecting things. You might select an image and then you might realize, hang on, wouldn't it be better to get it by the alt tag?
And you might realize you go no alt tag in your image and you're like, "Oh my god, I'm going to need to fix that." So you end up fixing your code as well by creating better tests, right? So it's mixing and creating your tests, improving your code. And it's a nice way to make sure your code is great and your tests are good.

Paul:
Speaking of checking for alt text, as a person who dabbles in front end but is not a front end person, that's something that I would almost never put in unless somebody told me to put in.

Debbie O'Brien:
What? Really? That's so terrible.

Paul:
I make websites for me and my brother and for this app I want to show off, and that's about it. I'm a backend person at heart. So when I hear, "I'm going to search by Alt text." If I was writing a website, I want alt text my things. I want to make sure it's SEO optimized, it's made for all sorts of content delivery. If I want to take a test that targeted alt text, is there a plugin community or can I go grab somebody else's end to end test or boilerplate somehow and use that?

Debbie O'Brien:
Wait, you can do accessibility testing with the Xcore plugin, so you can test that as well. But always with accessibility testing it's like when you do it with lighthouse tests and stuff, it's never a hundred percent sure on accessibility. So you really do need to always check that bit more.
But I think going back to your point, you said you don't put alt tags in, and this is the problem that people have. Right now on Twitter... I don't know if you're doing it now, when you put the alt tag in the image. Do you do that when you're adding an image to Twitter?

Paul:
Gosh, it's been like a year or two since I've made a front end project.

Debbie O'Brien:
No, but on Twitter, when you're sending a tweet, do you add an alt tag when you're sending a tweet?

Paul:
No.

Debbie O'Brien:
Well, you see, you should, because if you get in the habit of doing it, after a while it just becomes normal to add your tweet, submit your image and add the alt tag. And that's what we should be trying to get, is creating little habits. So when you're building your website, you automatically create that alt tag, you automatically put it in because it's a habit. And now here's where we need to change things. Testing should become a habit.
So when you create that page, you should now go and test that page. And once that becomes a habit, it's now not something like an afterthought, which is the problem right now. Testing is, once we finish the application, we're ready to hand it in, it's like, "Let's write tests." No, it should be a habit, something that gets done along the way just putting those alt tags in.

Paul:
Do you think that this mentality of testing is more prevalent in a front end context than a back end? I find that pushing the can down the road happens a lot because you get really involved with, "Wow, look at all these features we're making and cool UI things." And it's easy to delay testing but at least in some back end work you can't even go to phase two unless you figure out some data about phase one, which requires writing some automated tests and things like this. There is a little bit of a difference even though the problem is still extremely prevalent.

Debbie O'Brien:
Yeah, I think a lot of companies as well left testing to the QA engineers, and we're seeing a lot more now that developers are starting to test. So the front end developers or Full Stack developers are the ones who are writing the test. And then some companies now don't have QA engineers, or still have them, but that's your last step and you should be able to easily debug your tests on the developer side of things, and getting developers to write tests as a common standard.
And then your QA should be easy, everything should just work, which makes it easier. Obviously things break, so there's obviously a need still for QA engineers. And sometimes QA engineers are doing only the testing, which is also fine. So every company works different I think.

Paul:
Enjoy the podcast? Consider hitting that follow button for more great episodes.
So if people want to start testing, they hear what you're saying and they're like, "All right, we're going to try to change this for our project. We're going to go check out end to end testing." What is maybe a feature that you can broadcast that makes testing more approachable right now?

Debbie O'Brien:
So if you use VS code, you basically just go and go to the extensions and search for Playwright, install it, and then it's going to tell you, which browsers do you want to install? So you'll install Safari, Firefox, and Chromium. And install a GitHub actions workflow, so then it's going to work on CI automatically, on push and pull request, without you having to set up anything else, that's easy.
And then you install that and it comes with a little example test and all you got to do then is press the green triangle on the test file and you can run the test. So now in a matter of seconds you install, set it up, and run your first test. And then you can use the test generator to get you started and write your second test, which basically opens up a window, you start clicking away, it records your actions, it puts that in a test file, saved into VS code and now you've got a test.
Is it a perfect test? Maybe not. You need to go and then add some web assertions, make it a little bit better, improve it, but you've got test that up in five minutes. If I say to everyone, "In five minutes, go and test it out, give it a try. You'll have a test written."

Paul:
I think one of the most beautiful things that you just mentioned is the fact that you can do this all in VS code. That is a really awesome sandbox for a lot of people to try out new technologies. And so if people are taking one thing away from this, you can go install an extension. It's that simple.

Debbie O'Brien:
And it means you don't have to open the terminals. There's a lot of people who are term of fear and there's too many code, "What do I do?" This is all visual, which I love because it's like click beautiful green triangles, and the error messaging of your test breaks is really nice because it can tell you exactly where you're going wrong.
So it's a really nice way to get started and just never leave VS code. Just write your test and it'll open the browser and it'll show the test running. It'll open that browser and go through every step so you can visually see it as well, which is really helpful.

Paul:
So I can assume if you're using the test generator thing you talked about, which seems like magic to me, you're replicating the DOM actions that you're emitting onto this test page and it's going to document them and reperform them, correct?

Debbie O'Brien:
Yeah, so it just goes through all your actions and as you click it's going to put them on the page. It doesn't do a web assertion. So you've got to then go along and say, expect this button with text, gets started to be visible. So you can modify it a little bit. That's why I said you need to make your test a little bit better, but it will record every single interaction you do. Whatever you do, it's going to click and record that.

Paul:
I guess it produces some sort of declarative text file that is like, this is the test.

Debbie O'Brien:
It includes your test, so your actual test file, your spec test file, so the actual test. That's it. And then you just press play and it will run it.

Paul:
So it's almost... I can think of this test file as a script and it's going to do its thing. What if I recorded me, let's say, putting in a username, a password that was deliberately wrong and then I hit login and I want to expect some error and then I'm like, "Okay, this was cool but I want to try the set of well known sequel injection characters. I want to try a loop of things. I have this whole set of inputs I want to try." Is that something you could just go into a recorded test file and maybe make it into an iterative structure?

Debbie O'Brien:
I mean you're thinking kind of back end stuff, right?

Paul:
I am, yeah.

Debbie O'Brien:
Yeah, I see. So for the input, if you want to do testing reject stuff and whatever, that's something you do at a unit level and not at the end to end, because you're making sure that it works. So you're not looking for every single edge case of someone trying to inject something into your code. That's something more the back end, I would say, would take care of more than the front end.
Remember the front end is that the user is able to log in, they're able to add something that works and it logs in. And if they add a password that doesn't work, it should not log in, it should bring you to a... I don't know, 404 page or, you got to error message, click here and try again or send a new password, or whatever.

Paul:
I totally get that. I've seen a few tests in my time working when I dabble on the front end where people say, "Try this input, then try this input and then try this." But it's not massive, it's just there may be a few similar ones trying a similar progression where they intentionally error it out. Within this end to end testing framework, are there ways that you can modularize the test or is it very much like each one's its own functional component and then you'll build up your library from there?

Debbie O'Brien:
So you mentioned a word component there and there's two different things. So you've got component testing, you've got end to end testing. So you can basically take a whole functionality of say a shopping card and where does it start? It starts with going to the homepage of X shop and then literally searching for a product, and clicking that product and adding it into the shopping cart, and then paying for it and going through the whole process. And that's the end to end experience from start to end.
And then you've got the component testing which literally tests that component in isolation. So for example, the shopping cart, you want to test that you're able to add a product and remove a product from the cart, and you can put that shopping cart on any page. It could be in the header menu, in the big dropdown menu. It could be in the footer, it could be on another page. So you want to test that component works and then it can be slotted in anywhere, which is different then, to the end to end, going from start to finish.

Emily:
It's Emily again, producer for PodRocket and I want to talk to you, yeah you, the person who's listening but won't stop talking about your new favorite front end framework to your friends even though they don't want to hear about it anymore. Well I do want to hear about it because you are really important to us as a listener. So what do you think of PodRocket? What do you like best? What do you absolutely hate? What's the one thing in the entire world that you want to hear about? Edge computing? Weird little component libraries? How to become a productive developer when your WiFi is out?
I don't know, and that's the point. If you get in contact with us, you can rant about how we haven't had your favorite dev advocate on or tell us we're doing great, whatever. And if you do, we'll give you a $25 gift card. That's pretty sweet. So reach out to us. Links are in the description. $25 gift card.

Paul:
That thing I was hoping that you'd say, "Yes you can modulate." It's built in. It's built in via the way we build websites. You can test a component, you can have that component test. And can you take those component tests and build them into an end to end test?

Debbie O'Brien:
So component testing is a little bit different and you have to install the component testing, it's still experimental at the moment. Once you start building component test, that test lives in the component. It only tests that component and you can visually see that. So when you press play on your test, it will open up that browser and it will show the component in isolation. So it's got no header, it's got no footer, it's got nothing else, only whatever is in that component. If you have global styles you can add them in, but it will basically take that component as it is.
So you can test the component and say, "Yeah, this component works." Which is really good, especially if you're building component libraries and you're using that component across various companies or as a package. And then you've got your end to end testing, which you're testing that whole shopping card experience from end to end or any other part of the website. But the test can live side by side, you just have to run them differently, because running component tests and running your end to end tests are different commands, if that makes sense.

Paul:
Totally makes sense. It's like two different modules that you can build up with. So if people wanted to... Component testing is still, what you said, in beta?

Debbie O'Brien:
Yes. It's still experimental.

Paul:
So if people want to at least check out the thing Playwright is already excelling at, the end to end test, would you say it's better geared for one front end framework or the other? Or does it really lend itself to be as adaptable for svelte, next.js, plain old react? There's a lot of different server side static things going on these days.

Debbie O'Brien:
Yes. So for end to end testing you can test anything, you can test anything that's web based. So once it's in the browser and works in the browser you can test it, which means you know can test the Svelte app, you can test a Vue app, you can test any app. And then component testing, you can only test on Vue, React, and Svelte, because component testing uses Vite under the herd to add the preview bundle to be able to see the components and to bundle them. So that's what Vite supports. So that's why it doesn't support other frameworks because it basically it's based on Vite. But the end to end one supports absolutely everything and you can test any website and you can also emulate Safari mobile. So you can emulate a mobile device and test on mobile devices as well, once it's like an emulation.

Paul:
I was recently working with a group, we were making a Chrome extension and one of the biggest issues we came up with was, "All right this is great but it's basically an app, it looks like a phone app and how do we test that?" And the end to end testing framework that we were looking at at the time, which is very difficult to get set up with a mobile testing. So this is something that we can use now, a mobile test?

Debbie O'Brien:
Yeah. You just go into the play reconfig, and you can just select WebKit and it will emulate it. So it's not like you can't go to your mobile phone, it's emulating in the browser. But it takes the user agent, everything else that goes with that emulation, and runs it as if it is on a mobile device.

Paul:
And to throw out the note there, if anybody wants Playwright to work with another front end framework for the component testing, the secret here is to make Vite work. Plug it, go make a PR, figure it out, make Vite work for someone else. Really massive undertaking there but it'd be great. So of the issues that are being raised... Or not, I will say GitHub suggestions and issues and all those things. What is something that got worked on recently that you think the community got really excited about?

Debbie O'Brien:
That's a great question. There's so much, so I don't know.

Paul:
I know, it's like, what your favorite band, sort of question.

Debbie O'Brien:
The trace viewer has evolved a hell of a lot recently and I really love the kind of work that's gone into that, the test generator as well. But I think my favorite is probably the VS code extension because relatively in the last couple of weeks, the newer version is what shows the browser. So before you would run the test and it would just go green and you'd be like, "Okay it's green, but did that really work? What happened?"
Whereas actually being able to show the browser, and I'm still in VS code, all I'm doing now is pressing play like I did before and it opens that browser and it super fast goes through all the steps and that makes me confident that yes test actually worked, because I saw it. Even though Playwright tell me it worked but I didn't believe it because I didn't see it. And we're a bit like that, aren't we? If we don't see it, we don't believe it.

Paul:
Yep. We're human beings, that's right.

Debbie O'Brien:
So yeah, that's probably one of my favorite is the VS code extension. But so much has been... There's so much work being done, it's insane.

Paul:
What's something being done right now if people were to go poke around the repo, that's maybe overly ambitious, something really cool?

Debbie O'Brien:
I'll tell you something I want that I should be starting but this might take a while. But what I want on the test generator is the web first assertions to actually be there as well. So when I said about clicking and then you have to go and modify that test, I would love it to actually generate the assertions. That would be incredible. That's something that can be worked on, will be worked on. But there's a list of things to be done. But that would be super helpful. So that will come. It will come.

Paul:
It will come. Okay. Speaking of assertions, what are... I feel like assertion libraries, they have almost like a cult following. Sometimes there's some people that swear by one assertion library and it's like, "This is just the way they use it." And there's some special things in these assertion libraries like, "I really like the way you can check string fuzzy matching with this one or something." The assertion library that Playwright uses, is it homegrown? Are you plugin from somewhere else? And do you feel like it's ample enough to really do everything that you need to do? And are there any things that you love about the assertion library?

Debbie O'Brien:
So it's using Jest and [inaudible 00:22:22]. So you've got all the... So it means to be visible, to be checked, all that kind of stuff. But what gets on top of that is the auto wait issue. So it's auto wait all these, you don't have to add in timeouts, you don't have to manually do anything, it's just going to auto wait and make sure that selectors on the page. And then it's going to see, "Yes it's here, it's ready to be checked, it's ready to be clicked, et cetera." So it's kind of extra powerful on top of the...

Paul:
So it's using the power that we love of Jest, but we're not dealing with life cycle execution stuff. That's being taken care of by Playwright and they're really just using the linguistic pieces of Jest that we're used to? Okay, got you.

Debbie O'Brien:
I guess you could say that, yeah.

Paul:
So you're excited to hopefully get the assertions. So that's if we generate a test right off the bat, those assertions will just be kind of roped right in. That's what you're talking about?

Debbie O'Brien:
Yeah, because I think it will help people write better tests, because one of the things we're seeing is that people are writing tests but they're not using the correct selectors or the best assertions. And then they're going to add in timeouts in because things break and a lot of time [inaudible 00:23:29]. Well if they choose better assertions, better selectors, from the start, and if we can educate people by using the generator, I feel will help educate people. So then when they click something it's like, "This is the way I should write my test." And from there, they can go on writing tests, but now they're in a habit of doing the webs assertions first. It's all about habits.

Paul:
It's all about habits. I can't disagree Debbie. So I know you also have a YouTube channel where you post helpful developer content and, I don't know, there was some really friendly welcoming videos there, introducing people to some concepts. Do you have Playwright videos there? I actually didn't see one when I just was first poking around.

Debbie O'Brien:
I know, I actually literally created one today and then I'm watching it, I'm like, "Oh my god, is it good enough? Did I do it okay? Made a mistake, should I be re-recorded it?" Sometimes we just think too much. But yeah, the idea is to get those videos out as soon as possible. I've got a lot of conference stuff coming up and as soon as that's other way I'm going to concentrate on videos. Get them out on YouTube, hopefully onto the Playwright YouTube channel so you can follow that channel and the idea is to create loads of free content on there.

Paul:
Awesome. So this video is going to end up on the Playwright YouTube channel?

Debbie O'Brien:
Unless it's not good enough and that ends up in mine.

Paul:
Okay. And just in case, what again is the name of your channel if people wanted to go find some extra content?

Debbie O'Brien:
Just go to debbie.codes and then all the links are there, it's easier.

Paul:
Yeah, just moving into this section of the podcast, I wanted to point people in some direction if they wanted to either read about Playwright, watch about Playwright or start tooling right now with Playwright, where could we send them? So watching the Playwright YouTube channel, Debbie's YouTube channel, possibly in the future, there's also other great stuff there you should definitely check out.

Debbie O'Brien:
So on the docs we have a community section. So if you click on the community link it will open up, you'll see all our ambassadors. We have some amazing ambassadors who are also creating content and you can follow them and you can... I'm not creating .Net content, but we have an ambassador who is, so that's the person you should go to for some .Net videos for example. And then we have any conference talks from myself or other people who have spoken at conferences who are advocates or working on Playwright, their videos are there.
So you can watch previous conference talks and you can watch some of the release videos every month. There's new release from Playwright, there's new things happening and you can basically watch and see what was new and catch up on what you missed. If you miss it, then you're like, "There's two months of stuff." And it's like, "Oh my gosh, so much cool stuff has happened."

Paul:
So this is on the Playwright website, on their docs page we can [inaudible 00:26:09]?

Debbie O'Brien:
On Playwright.dev and click the community tab and everything is there and we'll keep building it up. We're going to do some case studies as well and have some stories of what people are doing in Playwright, how they're using it and their journey in Playwright and just make it very community based so we can learn from each other.

Paul:
And does that Playwright.dev site have any avenues for people to come contribute themselves, aside from the GitHub repo, forums to talk about, places to ask for help?

Debbie O'Brien:
Yeah, so the docs itself for contributions, we've had some people doing some amazing contributions to docs and creating some new pages for us and modifying that. So totally up for helping in the docs and making it better. And then there is a community Slack channel, so if we do have questions and stuff, there's a lot of people in the community there and people are very active, so it's really cool. Throw your question there and you're sure you're going to get help from someone in the community.

Paul:
And people can find the Slack from the Playwright.dev site, correct?

Debbie O'Brien:
Correct. Yes.

Paul:
Perfect. Okay. Well Debbie, thank you for your time and coming on and helping us all revisit testing because it's something, as you said, it's a habit that we should all be exercising.

Debbie O'Brien:
Five minutes. I'm telling everyone just take five minutes out of your day, try out Playwright just in VS code, give it a go, see what you think. Tell me on Twitter what you think and I'm sure you're going to love it.

Paul:
Where can people find you on Twitter? I'm not sure if we...

Debbie O'Brien:
Yeah, so Debs, D-E-B-S, _O'Brien is my Twitter handler and I pretty much live on Twitter, so you'll see me a lot there. And I tweet about Playwright. Well also tweet about running and cycling and doing all sorts of sports. So definitely follow me for any sort of crazy content on Twitter.

Paul:
For serotonin and development, perfect. Debbie, thank you for your time and hopefully some people will just go into VS code, five minutes, check it out. I know I will be, because I need to add alt text to my images-

Debbie O'Brien:
Yes, you do.

Paul:
That's what I needed today, so there we go. Well, thanks for coming on Debbie.

Debbie O'Brien:
Thank you very much for having me.

Emily:
Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcast.