Debbie O’Brien is a Senior Program Manager on the developer division community team at Microsoft. She returns to the show with Steve to talk about the Microsoft tool called “Playwright”. It is a framework for Web Testing and Automation. Moreover, they go into how the testing works, its useful features, and how it has more advantages than other testing solutions.

Hello everybody, welcome to another episode of Views on View. I am Steve Edwards, the host with the face for radio and the voice for being the mime, but I'm still your host. I'm flying solo today on the panel and with me, I have a very special returning guest, one of our faves, Debbie O'Brien, how you doing, Deb?

 

Woohoo! One of your faves. I love it!

 

Woohoo, yes, returning guests. Now the interesting thing about Debbie is that every time she comes back, she's doing

 

I have

 

something

 

a new

 

different.

 

job. I know.

 

She has a new job. So,

 

So this is the last time you're ever gonna get me.

 

all right, note that down. This is the last time that she's changing jobs is what she's saying basically. So, no, the first time, so the first time we talked to you, I think it was me and Lindsay, and you were with Nuxt. You were working for the Nuxt organization.

 

That's correct.

 

And then the next time you had just changed, and I'm sorry, I forget where you were, but you were doing React.

 

Yeah, it's called

 

And,

 

Accompanying a Bit in Israel.

 

right, right, you were doing React, and now you're with Microsoft.

 

Yeah.

 

So, going for the small, you know, personalized companies,

 

but

 

exactly.

 

still about open source. And I think that's the cool thing. I've gone from open source to open source to open source.

 

Yes, that is indeed most excellent, a trip down the open source lane that Microsoft has gone. So yeah, we can get into that for sure. Before we get into that, for people that have not heard the previous episodes or who could possibly live in the Vue world and not ever heard your name, why don't you give us a little background and who you are, what you do, why you're famous, and so on.

 

Famous, I didn't know I was famous. Um, so yeah, my name is Debbie O'Brien and basically I started out in open source many, many years back while I was working as a team lead in a company. Started out by contributing to Webpack, actually. Started out by contributing to documentation and it's really important that you can start in open source from just the smallest, tiniest things and end up like doing amazing things. So don't ever think you can't. And yeah, I live in Mallorca. It's a beautiful island off Spain. So I cycle and run around the island and do a lot of sport. You've probably seen that on Twitter. And I've been working in front end for many, many years in and out of jobs. I always find it difficult because I live on a small island. So yeah, finding companies to have long full-time jobs in tech was very difficult. I think COVID has been great because it's really opened the whole world that you can now jump. I can now work for Microsoft, whereas before COVID times that possibly, it wasn't gonna be possible, right? There's no Microsoft offices here. And yeah, what do I do? website called Debbie.Codes and I throw up on there all these kind of stuff like the podcast interviews blog posts, anything that I can do in my free time to help people out so that they can get a change their lives and get an amazing job in encoding anything I can do to help is there and my website is open source, it's built with Nuxt 3, upgraded to Nuxt 3 but yeah basically that's... That's probably why I'm famous because I'm just like always helping people. And then I just got recognition for that. And that helped a lot. But yeah, anything I can do to help people in coding is my goal, my dream.

 

So for those of you listening to Debbie, that is not a Majorcan accent that you're hearing that, yes,

 

Hahaha

 

yes, an Irish accent, just in case you might be confused, she's not a native Majorcan or Spaniard, so.

 

No, it's too cold in Ireland and it rains too much, so I moved over to the sun.

 

Sounds like me here in Oregon, let me tell ya. But

 

Hehehehe

 

anyway, so the first, tell us before we get into the topic, and before I forget, I always forget the studio audience. How you doing, studio? Thank you. I don't

 

Wow,

 

want

 

I

 

them

 

do

 

to...

 

have a lot of fans.

 

Yes, yes, we don't... Well, the ticket sales went through the roof when people

 

Wow.

 

heard that you were coming. It's the demand. I almost swamped Ticketmaster servers.

 

Me

 

But,

 

and Taylor.

 

so before we get into what we're gonna talk about, why don't you tell us about Microsoft? And for those who haven't heard of Microsoft, what it is you're doing there, especially since it is in the open source world.

 

Yeah, so it's funny because Microsoft was a goal of mine from like five, four years ago and it was like my five year goal. So I had been kind of building up to eventually be good enough to get a job at Microsoft. So that was, um, what I was doing four years ago when I started working for the companies I was working for. And that's why I was changing jobs and every job interview I would turn around, they would say like, where are you going to be in three years? And I would say, I'm going to be in Microsoft. And they would just look at me and say like, yeah, you're just a little girl that's coming in here for a job in a small island in New York and it's never going to happen. But I actually didn't think it was going to happen either. So I kind of agreed with them. But but yeah, it's amazing, like to go back to those managers and say, look where I am. And they're like so proud of me. So that's really cool. But yeah, I joined the Microsoft. team in May basically to work on Playwright and to be honest and I'm going to be very honest I did not come from a massive testing background I am a front-end developer I have been trying to get front-end developers into testing obviously I've used Cypress and you know Selenium and stuff but not to a massive massive degree right because every time we tried about testing into a project, the managers or the bosses or the clients would turn and say, we need to cook costs, let's just remove testing, let's just not test. And then like, you'd be like, Debbie fighting for testing and them saying, not gonna happen. So yeah, when I joined Microsoft, it was kind of like, I didn't even think I was gonna get the job. I was like, I'm not a testing expert, oh my God. And there's this new tool Playride that I do not know enough about. And now I'm like learning it like. 24 hours a day to try and, you know, pass the interview and to take on this responsibility. So it's been a wild, like crazy seven months. To get the job was like insane. I was like, oh my God, I made it. I made my dream come true. I get to work in open source. Playwright is open source and that's something I'm very passionate about. And I get to do testing, which is I really, really do enjoy even though I'm not an expert, but I will be. So yeah, it's been incredible. And I think Microsoft is an incredible company to work for, especially because the amount of open source work that we're doing, tools that we're creating for people, it's an incredible company.

 

Sorry, I got to unmute there, delay on the mute undoing. So yeah, so open source and Microsoft to me has always been sort of an interesting topic, just because I first started using Microsoft, and this will age me, back, Windows 3.1,

 

Wow.

 

early office days when I first got into my first software tech support job, we were supporting clients on Windows 3.1 and... I did more memory management than anything else in those days, you know, upper memory and lower memory and gives me the heebie-jeebies. But back then, Microsoft was very anti-open source. You know, I think one of the legends

 

Mm-hmm.

 

is it was either Bill Gates or Steve Ballmer was like, you know, compared open source to the devil or something like that. And the biggest change over the years was when Steve Ballmer left. to be honest, because he fought, he hated open source.

 

Yes.

 

I think Bill Gates did too. But once he left, things opened up and you started seeing stuff like the Linux kernel being incorporated into Windows and the use of open source JavaScript libraries and other tools at Microsoft, maybe like on Azure. And now... .. Microsoft owns GitHub, which is

 

Yep.

 

what the largest repository of open source code anywhere, and that probably makes some people nervous. And they make Visual Studio Code, which is probably one of the biggest, most popular IDEs used for open source projects. So yeah, it's been

 

And don't forget TypeScript.

 

TypeScript. Yes, yes. What is TypeScript? I've never heard of it. I'm kidding. I kid, I kid.

 

Hehehehe

 

So yeah. Yeah, they have definitely contributed a lot to the open source world for sure. So it's been quite an interesting evolution for lack of a better term in terms of Microsoft and embracing open source technologies. You

 

I

 

know,

 

think

 

and you

 

as

 

still

 

the world

 

have your

 

changes,

 

proprietary stuff,

 

you need to

 

right?

 

change with it, right? And

 

Yeah.

 

they made the right choice in changing and going down the open source world because we can gain so much from it and they're gaining from it and giving back is basically we're giving something back, but we're also gaining a lot as well.

 

Sure. Yeah, I mean, to be sure, there's still the closed source stuff, Microsoft Office and Windows. And a lot of that is still closed source, of course. But I remember one of the things that I noticed, you'd mentioned Microsoft contributing back, when Explorer went to Chromium and got rid of their own engine and went to Chromium. I remember seeing. I think it was on Twitter or Hacker News. I don't remember. But anyway, there had been a longstanding bug in Chromium. And within a very short time of Microsoft incorporating it, it had been fixed by a Microsoft engineer. And this had been like a bug that I guess had been around forever. So stuff like that, Microsoft contributing back to the web was certainly a welcome.

 

Everyone

 

Welcome.

 

wins.

 

uh, uh, happening for lack of a better term, my brain freezing. So with that, let's talk about why we're here and it's called Playwright. So Playwright is, uh, a testing front end testing and to end testing, I think would be the term tool for incorporating into one of your, uh, web projects. I think we talked about earlier and from what I've heard, it's sort of a direct, uh, uh, competitor to Cypress. which is another front-end testing tool. As I've mentioned before here in other episodes, I tend to use Dusk just because that's part of Laravel and where I work, we're a big Laravel shop with Vue on the front end, and so we use Dusk, and that has its advantages for Laravel developers in that you write the actual front-end test in PHP and then it, I think, uses jQuery under the hood. But anyway, we wanna talk about Playwright and what it is, how it works, why it's so awesome. and so on. So fire away, Deb. Tell us about Playwright.

 

Oh my God, where do I start? So yeah, let me just first go into like, you know, automation testing first. So there are still companies out there, there's still people out there who, and I used to be that person in one of those jobs, who sits there on a Friday. and test the application by literally clicking buttons and being the user and using the website, right? You push it to production, then you test it. And that's still happening, right? That should not, there should not be someone sitting at a computer pressing those buttons. So automated testing is basically, we're gonna automate that process by getting the computer basically to... to do all that because a computer is faster than us. They can type faster, click faster, everything. So imagine filling out one of these really long forms, right, to do whatever. You fill out that form once, you write the test for that, and then... every time you make a change to your code, that test is run against that form. It fills in that form, makes sure everything is okay, everything is validated. And this is like, I was doing a visa application the other day to go on a cruise, and I could not even fill out the form because it wouldn't let me. Stupid little things, and I was like going so mad. And I was saying to my husband, they don't use Playwright, they don't do testing. And he gets it, he's like, oh, this is so frustrating. So yeah, it's really important to test. especially like forms, logins, all those things, anything to do with money, that you're not gonna lose clients, et cetera. So what Playwright does is basically has that test done for you so it can rerun that test every time that you make a commit or a pull request. And then when it comes to testing, and this is what I love about Playwright is, cause a lot of people, and I know because I have literally sat there with a team of people trying to make them write tests. And I said to the developers, come on, you're gonna love this, trust me. And they're like, do I have to? And it's like, you're just, yeah, it's been so hard. So trying to make testing easy, fun, a way for developers to be able to just incorporate it into their day-to-day jobs so that we have better code. That's something I love about Playwright is because we have a test generator. So literally you can go to that form and you can be that user once and you can fill in everything that you need to fill in. And it's going to generate that whole test for you. Now you have that whole test on your job is done. You just, you just click buttons for 30 seconds and you have a test written and that's going to like be run against, you know, every PR and that's it. Now, obviously, you know, you need to improve tests a little bit, um, add some assertions that the generator is not going to generate for you. But in general, you can get up and running very, very quickly with Playwright and have those tests written. Even my mother can write tests. That's how easy it is. My mother is not a developer.

 

Okay, yeah, I thought we should clarify that

 

Hahaha

 

for a minute. So let's, I guess, talk basics. What are we writing tests in?

 

So that's your choice, right? Now I'm a JavaScript or TypeScript developer, so I'm gonna write my tests in the language that I'm comfortable with. But you could be a Java developer, or you could be a C-sharp developer, or you could be a Python developer, and you can write it in that. So, I'm gonna write my tests in the language that I'm comfortable with. So, I'm gonna write my tests in the language that I'm comfortable with. So, I'm gonna write my tests in the language that I'm comfortable with. code that makes you happier, right? Basically. So everyone should write the test in the code that makes them happier, that they understand. It's using the same library, so Playwright is basically multi-language. And even the generator, I could even write code in Java without knowing Java, right? Very easily, because it will just generate it in Java for me. and it's very understandable between the languages. So if you have multiple teams, you know, using different languages across your company, it's very easy for me to say, you know, I'm gonna use TypeScript because I know that, but you're C-sharp, you stick with that and you write it in that. I can still read their test and understand it. They can still read my test because we're using the same API.

 

Hmm, okay. So does that mean it has, Playwright has different what adapters or converters or compilers, I guess for the different languages? So that that what that you have to install that says, okay, I'm gonna write in PHP Java, whatever and then

 

Yeah,

 

it

 

so

 

Translates

 

you're,

 

everything for you

 

yeah, when you install it, you're gonna choose which you're gonna install, right? Whether you're gonna install it on Node, you're gonna install the C Sharp, and therefore you're gonna get the library based on what you installed, right? Based on like the test runner with Node is gonna have everything in it. And for C Sharp, you've gotta add your own test runner, like NUnit, for example, MS Test, another one.

 

Okay. So you've installed it and you've said, okay, I'm gonna write them in node, you know, just for,

 

Yes.

 

to use a popular one. So for this test generator, and I'm reading through the docs here,

 

Hehehe

 

you basically get it running and then you go navigate your, it looks like you navigate through your forms or your window, whatever, and behind the scenes, it's sort of tracking what you're doing and generating the tests that do what you want. Is that correct?

 

Yeah, so it's gonna generate on every click event, so, or type event field. So whatever you're doing as in user interaction could be going to clicking to go to a new page, for example, checking the menu works. So that's gonna then be recorded. And now here's the cool thing. You could be doing it, you know, from the CLI by running a command, and then you just copy that code and put it in your editor of choice, or you can use the VS Code extension and therefore like right from VS Code, You're just going to click a button, it's going to open a browser, you click around, and it's going to already create a file for you in VS Code with all that test in there. So you don't even have to like do anything, you just press save at the end. That's it done. Happy days. Which is kind of cool.

 

OK, so I can see how that would track what you're doing. But it would seem that you're going to have to tweak it with assertions, right? Because something I run into or that we do when writing front end tests a lot is, OK, I want to make sure maybe this text is here or this. element is on the page or this, sometimes this element is not on the page, you know, because you've deleted

 

Yeah.

 

something or you've searched and something went away or something like that, right? So it's, I'm going to guess the generator can't really write assertions for what you're looking for to identify the yes, it was successful or not. And you're going to have to fill those in. Is that correct?

 

Exactly. So at the moment, I mean, I would love it to happen and maybe it will, but at the moment we don't generate assertions. But you can say click on, like, let's give us a very simple example, a header. You can click on that header, which is not a click, but once you click on it, it's going to generate that one. And then you could modify it. It's going to have that get by roll. heading and then name equals whatever is the heading name and then you can just remove the click event and turn it into an assertion and say expect to be visible. So it's really easy to refactor it but also if you really like you know writing everything from scratch you could just start writing it and you could use the pick locator because maybe you're like thinking how am I going to locate that heading and I'm using heading as a simple example right. You could say, do I use get by text? Do I use get by role? What role is a heading? So like, you can basically just use pick locator, hover over what it is and then click it. Once you click it, it's gonna actually save it then into these pick locator box in VS code or in the little box if you're using the CLI. And then you can just put that into your code. So you don't have to start inspecting the DOM to try and find a locator, right? You... don't have to spend all the time doing it because the generator is gonna help you writing your tests, even writing your assertions by using the pick locator.

 

OK. So as I'm going through and writing my tests, or let's say I've written one from scratch or say I've even taken one that's been generated and I'm tweaking it. So I can run it from a command line, is that right? Or this VS Code extension. Click on something to run a test and see what happens.

 

Yeah,

 

How

 

you can

 

is

 

click

 

that?

 

a little

 

Uh-huh.

 

green triangle in VS code to run the tests. And then it'll just run it right there. So you can run like in headless mode where you don't see anything. It's just gonna run it really quickly. Press a green. tick and it's happy days done. Or you can click a button called show browser and it's gonna like pop up the browser and you can actually visually see it doing its stuff. And then kind of say, yeah, that looks good. Even though it was really fast. But yeah, you could slow it down if you wanted to. But also you can like open it up on different browsers. So you can kind of say, you know, I wanna see this on WebKit because I specifically know it's gonna cause a problem on this and I wanna actually visually see it working on WebKit. So you can basically, yeah, visually see it on any of the browsers you want.

 

Excellent. OK. So yeah, for me, I always do it by default headless. Or excuse me, not headless. I turn it off. I want to see the browser.

 

Yeah, me too.

 

Because what I've experienced from a code standpoint is in your terminal, say, OK, it failed at such and such a line in this particular test. But I'm like, OK, why? Now, one

 

Mm-hmm.

 

of the the. One of the things that we do with our testing, and I'm curious to see how Playwright does this, and this might be more of a deployment environment thing, is we have it set up so any time we deploy code to a particular branch, it runs through our whole test suite on, we're using CircleCI. And one of the things that CircleCI provides for you is logs and then like artifacts.

 

Uh-huh.

 

So this is a picture of what's going on at your screen. when this error happened. And what I've noticed sometimes is that, if you look at the log and you see where it failed, it's like something was unavailable. You couldn't click on this particular button like you wanted to because it wasn't clickable for whatever reason. And that can be any number of things. Maybe you've got a condition that it's disabled until such-and-such field is filled in. But the one that I've seen that's helped me out quite a bit is because there's some error box. error message in front of your element that makes it not able to be clicked on because something else is wrong. It could be a return code from your backend, you know, 404 or something like that, and that's blocking it. And so is that something that Playwright does, you know, saves artifacts and stuff, or is that more of a deployment environment type of setting?

 

Yeah, no, so you can do the whole like, you know, video screenshot is what a lot of people look for, but we also have something called a trace viewer, which is even better. So the trace viewer gives you a whole trace of your test. And it's kind of like, it saves like as a PWA, so you can launch it as a PWA and actually then visually go through it. And there's a timeline at the very, very top. Think of the timeline as in like the Chrome browser or DevTools timeline, and you can kind

 

Mm-hmm.

 

of like hover. over it and it's going to give you a visual screenshot of the state of the page on every one of those events that happened. So you kind of hover over it in your own time, see what happens. And then down the bottom you have on one side all these kind of like, you know, what was happening. So every single step of the test. In the middle you have the DOM snapshot, which is not an image snapshot, a DOM snapshot, which means you can inspect it and open the Chrome DevTools right there in that. snapshot of the test and you have the before and after so you can see what playwright was clicking, what happened before, what happened after, so you can really try and understand what playwright was trying to do and what was covering up that button that you couldn't click for example. It also shows if there were other consoles, any console errors, any network requests that failed and the test code is there as well. So say you wanted to send that to a developer that didn't write that test but you wanted their opinion on it. the code is right there, they can kind of see, hey, but I'm lying, you know, 50, and you've got this problem, that that's what's causing it. Or you can actually just go to the logs and, you know, Playwright will say, hey, look, I tried to do this, but it's out of viewport. And then because you've got Chrome DevTools, you can open up the Chrome DevTools and you can like hover over it and you can see like, oh wow, look, it's completely out of viewport. Say like a mobile menu and the mobile menu's out of viewport and Playwright couldn't click it because it's not there. and then you can really understand what's going on. So the Trace Viewer is something that is set up on CI and runs on first retry by default, but it's something that you can do locally if you want by just putting a little flag after your test, dash dash trace on, and then it's gonna actually create that trace locally. And then you can locally kind of go through it, which is really good for local debugging.

 

Yes. Yes, I'm all about local debugging. So just to clarify, again, I'm looking at the doc pages on the Trace Viewer stuff. This is all stuff that you get on your local, right? The screenshots and the DOM snapshots and all of that.

 

Yeah, yeah, so you can do dash dash trace on and even if your test passes, it doesn't have to fail now because you're doing it locally. You can always also set it on CI to have a trace for every single. but that would be terrible

 

Right.

 

because then you're like using space, right?

 

Right.

 

But locally, just do dash dash trace on and then like, obviously you don't need to do it all the time because you don't need to always understand what your test is doing, but when you have a problem, when you have something you can't figure out, when your test is failing, you're like, why is this failing? Just run it with dash dash trace on and then just go through it and see what Playwright is doing, and then you can kind of like understand it a lot better, especially if you like... you know what the DOM was meant to do and you can go into the CSS and see if something was hidden. I found a couple of times actually where they had a CSS hidden class and they were like hiding it on mobile and that's why the test failed. And I was like, why is this failing? It's like, dad, display none, look at that. Look at that, I found you.

 

Ha ha ha ha. So let's go through the docs here again. So let's talk about parameterized tests. What is that?

 

Um, I would have to

 

Oh,

 

look it up myself. I

 

oh,

 

don't know. What

 

I

 

are

 

stumped

 

you asking me?

 

the expert. Okay, so it's multiple test projects at the same time. One or two projects with different options. Okay. So it looks like you're passing in, oh, OK. Well, that's cool. So you can run a test and basically dynamically pass in different pieces of data that are needed by the test so that you can run the same test just from different environments and not have to have

 

Yeah.

 

two whole separate suites of tests because this is different and this is different only because of data.

 

Yes, correct. There's

 

You learned something

 

so

 

new today.

 

many. Yeah, I haven't done that actually. This is the one with Bob and Alice, right, in the docs. They have a great example, but I've never had the need to do it yet. But yeah, there's so many things you can do, which is like, makes it very cool. But yeah, if you've gone through the docs, like we have so much from, you know. accessibility testing, visual regression testing, mock APIs.

 

Oof.

 

Yeah.

 

That's nice. Yeah, the mock APIs are basically a way to generate it. And I'd be the API for data that you need during your test, instead of having to hit a real API endpoint, which you probably don't want to do like hit production. And running test, I'm gonna take down my production because I'm hitting all these APIs, right?

 

Yeah, I used to do that. I didn't know you like, do you know what I mean? You're just like testing it out. Yes, it works. And you're like, actually, no, that's not what you should be testing. Ha ha ha.

 

Oh, right. Yeah, that's the thing about tests and computers in general, they do what you tell them to do, not what you want them to do.

 

Yeah.

 

Right? So you got this great test written and it comes back, but it's really not what you needed to test. So that's, I mean, there's only so much an automated test generator can do, right? You can't really

 

Exactly, because if

 

read your

 

you're

 

mind

 

gen...

 

and know what you need to test, what you really, really need to test.

 

If you generate your tasks and like say you go to your social networks to test that, you know, it goes to Twitter, for example.

 

Mm-hmm.

 

That's what the test is going to write for you and it's going to generate for you. But that's not

 

Mm-hmm.

 

good because now we're hitting Twitter and, you know, it might not even work because there might be some sort of like sign in modal that comes up. And now you're going to have this problem of checking if Twitter is that really my Twitter account, etc. But yeah, you can intercept routes and stuff. That's something I only learned recently,

 

Mm-hmm.

 

which is really, really cool. So you can like intercept that route. before it goes to Twitter's server, it's gonna like, you know, I say, give me a mock Twitter page, which just says Debbie's Twitter, and then like it tests that and it comes back. So what it's really testing is that link is actually clickable, that it's able to find it and it's gonna go to that place, but we're not gonna test that the server gave back Debbie on Twitter, because that's up to Twitter to do that, right?

 

Right, right. So one of the things you had mentioned was the ability to test across browsers and other environments. And in the emulation section, I find this interesting, is that you can also emulate real devices, like a mobile phone or a tablet. So you have to tell it, OK, I want to test on this and this and this. And it simulates. one of those types of browsers, instead of just always assume you know it's on a desktop, because the vast majority of people are looking at web pages on a desktop, right?

 

Yeah, like...

 

I'm kidding.

 

Yeah, like the same as well, you know, my test doesn't work on mobile Safari and it's like, why does it not work on mobile Safari? And there's little things like, yeah, but you've got a mobile hamburger menu, the user's gotta click that, that's an extra click that you didn't write in your test. And I asked this question a couple of times on stage and I said like, you know, what do we do in this situation? And a lot of people went, we just write two tests. And I'm like, what, you're gonna write two tests, one test for desktop, one test for mobile, seriously, just because

 

Ugh.

 

you have to click an extra button?

 

All

 

But

 

right.

 

like, They couldn't figure out how to do it if not, like what do you do? And I was the same, I was like, how do I do this? Can I not just like, you know, if it's mobile, just click that button. And that's exactly what you can do. You can just put if is mobile, and then locate hamburger menu, you know, get by roll button menu, click. and then close that if is mobile, and then continue your test. And that's kind

 

Mm-hmm.

 

of really cool because that's what the user would do. They would have to click that mobile menu button and maybe close it if they didn't wanna click anything whenever, but the fact that you can write one test and actually just say, you know what, if you're mobile, go this, and then you can test it not just on Safari, you can test it on any mobile device that you wanna test it on.

 

Yeah, that's really strange though that you would have an error on Safari that's not on any other browser. That would never happen.

 

Hahaha!

 

For sure. What else can we do with Playwright that we haven't talked about or any other features that you can think of that make it so better, shall we say, than the competitors?

 

I mean, Playwright is super fast. I think that's one of the things a lot of people just, the wow factor for them is like how fast your tests run. And it's really important because everybody's busy. You don't want to be like, oh, I'm making a poll request and it's going to run the test. I'm going to go have a coffee, have a sandwich, come back and maybe they'll have finished, right? You want to be able to have things

 

Ha ha

 

done

 

ha.

 

fast. Tests run in parallel, like just for free out of the box, just automatically. So, you know, everything is running in parallel. which makes it just like super fast. And then like you can do extra stuff, right? You can add more workers, you can do sharding, you do all that kind of stuff and have them, you know, even faster than that. But yeah, it's super fast. I think that's really, really important. Another couple of things is that you can test across multiple domains. This is really handy if you are using a chat application, for example, and you wanted to test, you know, like that I'm chatting to that. other browser window and that's kind of chatting back to me and I can test that whole integration that everything works. You don't have to do anything, it just works. So it's just like a lot of the stuff about Playwright is it just works, you just do it. I-Frames, it just works, you just test an I-Frame. Just use the pick locator and it'll just find that I-Frame for you and you know give you that but it's just like I-Frame, like frame locator instead of page, right? So yeah there's a lot of cool things. that we've solved the problem that people have had previously where people were struggling and one of the things is that, yeah, playwrights solve that problem. So that's kind of very cool.

 

It's in there. What's the... Gosh, there was an old commercial for like some... It was a food and the tagline was, does it have this? It's in there.

 

Yeah.

 

Or can it do this? It's in there. I think it was like a spaghetti sauce or something. I forget what it was, but yeah, that's what it sort of reminds me of.

 

Yeah, and TypeScript by default, like TypeScript first, because obviously like, you know, Microsoft, but it's just that that's where everyone's going, right? Everyone is, you know, starting to work with TypeScript. But one of the things I love about the fact that you can write your tests in TypeScript, you don't even have to know any TypeScript. You just have to put a TS extension on your test file and you can test your JavaScript code, right? Cause you're testing within the browser really, but you don't have to actually write TypeScript, you're just writing your tests in TypeScript. What you get is better integration in your IDE, for example, it's gonna tell you what's available to you and it's gonna

 

Oof.

 

underline any mistakes you have. So it makes the experience a lot better. And I think when people are choosing, they're like, they see TypeScript and they go, oh my God, TypeScript. And then like, they just go, I'll go with the JavaScript. And it's like, no, like actually install a TypeScript because, you know, it's just compiling. That's all it's, you know, you don't need to do anything. extra to get all the benefits and that's that's what's really important.

 

And just to clarify, that's, I mean, VS code, obviously, because Microsoft owns VS code and Playwright and TypeScript, all this, it's going to be pretty tightly integrated. But that's not to say you couldn't use another IDE or tool for, for writing your tests and getting, you know, a lot of those benefits. Like we use, in my shop, we use PHP Storm just because we write

 

Exactly.

 

a lot of PHP and it really works for us, uh, in our setup. So, you know, TypeScript is, TypeScript is TypeScript, right? So you're going to,

 

Yes, you're

 

you're

 

going

 

going

 

to

 

to

 

get

 

get.

 

it in any of the adatures. Yes.

 

Yeah, the code hinting and testing those. Yeah, we rely on those quite a bit. So yeah, that's nice to have for sure. So looking at, you know, I mentioned we use CircleCI and you've got Travis CI, there's GitHub actions. Obviously there's some

 

Integration

 

custom stuff.

 

with GitHub!

 

GitHub actions, that's really odd. Right, so yeah, so it creates your YAML file and will, you know, pull your branches and run this and that, and that's awesome. And then there's also a setting. for continuous integration for other packages,

 

Yeah,

 

as

 

see.

 

well as GitHub Actions, Docker, Azure Pipeline, Azure, oh, that's Microsoft too, yes. And even have a section on CircleCI,

 

Yeah.

 

again, the platform that we run. So yeah, it looks like you have, ooh, even Jenkins, going back to Jenkins, Bitbucket,

 

Yeah.

 

and so on. So yeah, it's a lot

 

Yeah,

 

of pre-built stuff that makes it easy to integrate.

 

I think that's kind of important to point out, you know. because we're talking about a lot of integrations and we work with all the Microsoft products, etc. But you don't have to. You can totally use whatever you want. Playwright is open source. It's free. So you can go and use it on any other editor. You can go and use CircleCI or whatever that you want to use. The only thing is that you can't tell a company, oh, change and move to GitHub because we think GitHub is better, because we are Microsoft and we have a better integration. No, your company has already got their system set up. They're going to use that. cool. But if anyone is starting out, the GitHub integration is just incredible. And especially if you're using the VS code extension, because when you install, it's just literally tick a box, tick the box to say like, do you know, do you want to get up actions, you just tick it. And now this is all created for you. So when you create your repository in GitHub and just push your code, that's it. It's all done. Your tests are now gonna run every pull request. And you don't have to do anything. It just works. It's like writing the docs for this page. It just works. Just tick the box and then it works.

 

Now looking at the supported language pages we had talked about, I don't think we can do it anything unless I'm reading this correctly because the options listed down here are JavaScript and TypeScript, Python, Java and.NET.

 

Correct.

 

Is there any work to add other languages, say PHP, which is a sort of popular web development platform?

 

Not that I'm aware

 

Or language?

 

of, but you could submit a question on GitHub and ask the engineers that. We do a lot of work with the GitHub issues, so if you had like that, you know, request or that question, you could submit it there and they would answer as to if that's gonna happen, if it's not, why, why not, etc. But as far as I know, it's not on the roadmap, but I don't know if... it's because of a demand issue or if it's just like because it's more, you know, I don't know, back end, you're not testing much in the front end, you could just use, we just kind of assume all the page people know JavaScript and TypeScript, that's what I would assume.

 

But you

 

You

 

know

 

all

 

the

 

know,

 

dangers of assuming, right?

 

you all know Vue, right? You all, you know,

 

Yes.

 

tailored

 

Yes.

 

at all, you know, you all know Vue now.

 

Like I said, for instance, well, somebody coming from Dusk, you know, all of our, the dust tests, even though they're front end tests are written in PHP. So that would, granted, yeah, you could say we use JavaScript because that's what we're using on the front end, but it just ought to be worth asking. Yeah, maybe I'll go in and add a question about there. To see what the plans are because like I said PHP is you know if you look in terms of what back-end languages are Used on the web. It's pretty dominant between You know Drupal and WordPress and in Joomla and craft and a lot of the CMS is that are out there

 

Yep, for sure.

 

So I think would be one worth at least looking at for sure Well, I think we've made our way through the Through all the documents anything else we missing talking about playwright

 

Um, yeah, we covered all browsers, um, auto waiting, maybe, yeah, auto waiting and assertions. So like one of the great things about the assertions we have, um, is that they will auto wait. And what that means is it's going to like, wait for your DOM to be loaded for that, say we're gonna use a button here, for example, wait for that button to be clickable. And then when it is, then Playwright is gonna perform that action. So you don't have to start writing timeouts or kind of thinking like, how long is it gonna take for that to be ready? And there's an animation to go for us. Playwright will just wait, it'll just do everything for you. So that's really, really cool to point out. And also test isolation. So by default, again, just works. All your tests are isolated. happens in one test, like whatever happens in Vegas stays in Vegas, whatever happens in one test stays in that one test. And whatever happens in the other test, you know, it's gonna get up, it's gonna like say, let me kind of put it in a way that it's gonna open up a new incognito browser window, right, that knows nothing about what happened in the other browser window. So if you clicked on event, a link for example, that's not gonna have that link clicked in that other test. So that kind of means you don't have to clean up, you don't have to do anything, like it just, you have basically everything running, new and fresh in an isolation. So yeah, that just, it just playwright just works like that. And then we have the locators. So we talked a little bit about how to locate, using the generator and stuff. And we recently like improved our locators a lot by using testing library inspired locators. So if you've ever used testing library, So things like get by role, get by test ID, if you wanna use a test ID for example, but we wanna kind of go towards user facing role. So what is the user seeing? The user seeing a button, they're seeing a link, they're seeing a heading. Well, you could use a get by role button for example, or you could use a test ID, right? And now you've got the two differences. A lot of people say, oh, we put the test ID everywhere, we'll change all our code and we'll add this in. But then what if somebody changes that button to a link, for example, right? Because the designer made it look different. Now your actually test is a little bit different, right? Whereas testing user, you're also testing now accessibility or making sure that button actually is a button, that it's not a link or that link is actually a link and not a button. It might look like a button, right? So yeah, basically kind of focused towards the user facing roles to improve accessibility testing. But obviously like we do have the... you know, test ID if you want to, if you need to. But basically the get by role is our big improvement and a lot of other locators in there as well. So we have a whole document on locators, which you've probably got now open.

 

I do.

 

So think about a form you might want to get by like, say the label or the placeholder of that form element. You can also do get by text, right? Which is, you know, maybe that text should never change. my name on my website, my name should never change. Someone should not make a P or to change my name. So that would be a good kind of way of get by text. But if that text is gonna change, then obviously like, you know, you might need something different, like, you know, get by a list item for a lot of like product card items, et cetera. But yeah, they're all basically in there. I wrote a doc as well recently on how to choose locators and which locators and et cetera. So you can find that on my website.

 

So

 

on the

 

when

 

Playwright

 

we talk

 

Dev2.

 

about, right. So are we, when you say roll, are those aria rolls? Or,

 

Yeah.

 

okay.

 

Yeah. So like, well, like the implicit role that the, that, um, that a button has, a button is not just an area role, it's implicit role of button, right? But then you could add an area role and then it's going to have get by role, whatever that area role that you added. So you could turn a div into a button, right? And then now you could say get by role button because you wrote area role button, but you shouldn't use a div with an area role of button. You should just use a button, for example. But yes, it will respect the area labels, area roles as well.

 

So within your elements, is there a way to define labels or IDs that are specific only to testing that make it easier? So let me illustrate with one of the things that you can do in dusk is that in your elements, you can define, you say dusk equals whatever, you know, whatever arbitrary identifier you want for that particular element. And the only place it comes to matter, The only place it matters is when you're running your desk test. So when you're running through your test and you want to see is something present or is something missing or does it have the right value, you just put an at sign in front of that identifier that you created, my custom desk element, whatever. And that makes it very easy, instead of having to use some complex CSS rule or to use some attribute that may or may not be there. So

 

Exactly what

 

it's

 

you

 

way

 

should

 

to

 

and

 

add.

 

use, right? Because then like that somebody could change that and they don't

 

Right.

 

know that you've associated it with your test.

 

Right, it's brittle. Can you do that with Playwright where you can say, okay, when I'm testing, just identify this text field by this name and look for it.

 

Yeah, so you we have like a data dash test ID, which is like predefined one, but you could totally change that in the configuration and you could say Debbie's test ID, for example, a Debbie's data test, whatever you wanna put, right? And then like you change that and then you can basically locate based on that test ID. But yeah, basically the test ID is there, works the same as you would in another test.

 

So that's using the native data attribute on the element then?

 

It's using the data test ID attribute that, that like obviously you will put it on your, on the code. You're gonna have to manually write in there that

 

Right.

 

data attribute, right?

 

Right.

 

Where you wanna put it. And then you can test against that. And if someone sees test ID, they're not gonna, data dash test ID for example, they're normally not gonna delete that because they know it has to do with a test.

 

Right, okay, so locate by test ID. What do you know, it's in the docs.

 

Yeah

 

RTFM, baby, RTFM. So, okay, good, yeah, because that's a real headache sometimes that trying to identify something by some CSS selector

 

Like, yeah,

 

or

 

like

 

text.

 

if you do not have access to the code, then you know, if that's the only thing you have, then use a CSS selector. But in general, it's like, just don't use CSS selectors because your CSS is gonna change. Your, someone on the team is gonna change. They come along and they're gonna change from bootstrap to tailwind. Now, oh my God, now you're gone completely, right?

 

Yes, I know exactly what you mean. Or this is view, maybe they go to Viewtify, who knows?

 

Yeah.

 

So, all righty. Well, that's awesome. I certainly gotta have to pull this in and actually do testing, kicking and screaming.

 

I-

 

From doing it professionally all the time, every day, I've definitely seen the value of tests and how they've caught things that... you know, that inadvertently change or, you know, one change here broke something way downstream. So on my personal projects, I think I'm gonna have to start doing the same thing much as I don't want to at times.

 

You do want to. This is the attitude. We're going to change this attitude. We want to test. We love testing and testing is

 

Yes.

 

fun and easy and cool.

 

Yes, when it becomes easier, then yeah, you're sure, then you're more likely to do it, shall we say.

 

Well, it's like when I moved from Vue to React, right? And I was like, React was just hard and difficult. It's almost like, I just want to write my Vue applications again, right? But now

 

Yes.

 

I'm like, now I know React. I actually really love React. And I think a lot of people say, I don't like this because they don't know how to do it. And if we can help people know how to do something, they're going to love it.

 

Just so you know, saying I love React on a view podcast is hair-

 

hahahaha

 

it's generally considered heresy, but we'll let it slide this time just because of who you are.

 

Sorry.

 

I kid, I kid people, don't uh don't flame me on Twitter or anything, okay? So

 

Hehehe

 

All right, so the site for Playwright is playwright.dev. Love

 

Correct.

 

those new top level domains you can get. The docs look pretty amazing, pretty detailed.

 

Thanks.

 

Everything that we've talked about is outlined in the documents here. So give it a try. And with that, we'll move on. Oh, sorry, before we move on.

 

I would just say start with it getting started, because I created it. No, because I've built it in a way that in basically like five minutes, you should be able to have a test up and running on CI. So that's the mission, and I think you can all do that.

 

Yes, yeah, it looks pretty straightforward and pretty easy, at least according to the docs. I'll have to, I'll give it a shot here soon, for sure. All right, now, now we will move on to two picks. Picks are the part of the pro show program, however you wanna call it, where we get to talk about things that are not tech related, or maybe they are tech related, you know, just something that you find interesting. We've talked about food and books and tools and... movies and toys and you name it. So I will go first. And as I always like to say, the high point of any of my episodes are the dad jokes of the week. Debbie's going, oh my gosh. So,

 

I'm taking notes.

 

right, right. What not to do on a podcast,

 

Hahaha!

 

right? So, first question, you know, think of all the Marvel movies or the superhero movies, Iron Man and so on. And this is one little known behind the scenes type of thing. Do you know why Iron Man and Aquaman never got along? They had rust issues.

 

Oh, God.

 

Right? So cow jokes, you know, I got a couple of the cow jokes. I always appreciate expanding my cow jokes from the basic, you know, what do you call a cow with no legs, ground beef type stuff to what do you call a cow who's done amazing things in her life? Legendary.

 

It's kind

 

Dairy.

 

of like cool, it's kind of like cool but almost a little bit offensive in a way, you know what I mean? So, I can

 

Dairy.

 

so see my brothers using that.

 

And somebody pointed out to me the other day that cow farts are dairy error.

 

Yeah

 

You know, dairy, or anyway, sorry. That was ruined when you gotta explain them. And then finally, this is in honor of Drew Baker, who's been a guest host, wasn't able to make it today. The other day I was watching an Australian baking show. You know, we get a lot of Australian baking shows up here in the States. And you know, meringue, you know, like a lemon meringue pie is really difficult to make. You know, it can fall flat and do whatever. So. Everybody cheered when one of the contestants successfully made meringue. But that surprised me because I always thought Australians usually boo meringue. So anyway, those are the dad jokes of the week. Debbie, what do you got for us for a pic?

 

Okay, I've got three.

 

Three,

 

Yeah,

 

count them three

 

I'm gonna just

 

picks.

 

go with it. So the first

 

Ha ha.

 

one is, the first one is like a shameless plug actually. The first one is Discord. So we moved the Playwright community to Discord literally like less than 24 hours ago. So if you're

 

Oh

 

not

 

wow.

 

there, it's because you just haven't found out yet cause it's like hot news. So yeah, join us on Discord cause it's like gonna be fun in there and we're gonna do a lot of. kind of cool and fun things with the community. We've got like hundreds of community members in there already, so it's really amazing. So yes, Discord, playwriting Discord. Second one, keeping with

 

How

 

the

 

do you

 

P's.

 

find it? Is there, sorry, before you

 

Oh,

 

go on,

 

go

 

how do

 

on.

 

you find it? Is there like a link from the docs page or you just search for

 

Oh.

 

Playwright in Discord or how does that work?

 

I thought you meant how do you find it as in what do you think of it? Yes.

 

Oh no.

 

So yeah, we've basically put it everywhere, but I haven't put it on the docs, but I've kind of like sneakily redirected the Slack link to Discord. So if you see the word Slack, you'll just go to Discord.

 

in the documentation.

 

Yeah, at the very bottom of the footer.

 

Oh.

 

It's like our sneaky way in, right? But we're...

 

There it is

 

Yeah, we're gonna like properly change it soon. We like it, it's so new. So that's why like we still haven't updated everything.

 

Okay, so Discord number one pick.

 

Woohoo! Number two, keeping with the P's, the pyramids. I was literally in Egypt less than two weeks ago and I got to see the pyramids for the first time and they are insanely impressive and I highly recommend everyone go to Egypt and see the pyramids. If that should be on your to-do list, top priority, make it happen, there you go. If I can

 

Yeah.

 

do it, you can do it.

 

Yeah, that would be pretty neat to see those. One of those things you know, you read about and see in books and stuff all the time, but I'm gonna guess that pictures don't really do it justice as compared to actually being there, right?

 

Just the fact that it's still there after all those years, like they had amazing engineers who like literally

 

Right.

 

built something that stood there for so long and it's still as beautiful as when they built it. And I mean, they must have done testing, right? I'm sure of it. Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

I think

 

ha

 

for them

 

ha

 

it would be more

 

ha

 

hardware

 

ha ha ha ha

 

testing

 

ha ha ha

 

than

 

ha ha

 

software

 

ha

 

testing.

 

ha ha ha  So I don't really do a lot of TV. I'm more of a sports person. So when I find something that I actually like, it's like, I might as well kind of share it. And this is a little bit like, almost like it's for kids. Kind of think it's like aimed at the kids more than anything. But Wednesday, the Addams Family kind of knew Tim Burton. Wednesday, it's actually really good. It's actually really funny. And the main character, I think she's amazing. I think she's got a great future ahead of herself. But yeah, I would. Sit down, watch Wednesday, book your trip to the pyramids and then get on Discord and chat to us about Playwright.

 

Yes, I'm already in the room.

 

Ha

 

So

 

ha!

 

yes, it's their playwright. It's got the little icon with like the Shakespearean type of masks, a red and a green one. So

 

Yes.

 

cool. And Wednesday, yes. I can remember watching some of the very original Adam's Family, you know, the black and white TV show from what was it, 50s and 60s, I think, and Gomez Adams and a little Wednesday. So yeah, I might have to. Pony up and watch this. I've heard good things

 

Good.

 

about it. I mean, she's rather, does she smile during the whole thing

 

I

 

ever?

 

think she smiled twice.

 

Oh, really? Okay.

 

Yeah.

 

Yeah, that's her thing is sort

 

Like

 

of

 

she

 

the.

 

really held it, like it was, you know, it was really impressive. And the smile was like, you needed it in that moment. But like she's played that character very, very well. It's really cool.

 

You know, I've heard that the one character that really sort of steals the show is the Hand. Is

 

Yeah,

 

that...

 

the hand is amazing. It's just brilliant how it's done. It's incredible. I think it's great.

 

Huh, yeah, I'd have to check it out. Put the link to that in the show notes to at least some information about it.

 

Cool.

 

Alrighty, well thank you for coming yet again. That's a hat trick for you, Views on View.

 

Woohoo! Ha ha ha!

 

Talking all about playwright. If people want to read what you have to say or give you money or whatever, what's the best places to do that?

 

Yeah, I love it. Give me money. You can buy me beers. There's a link on my website to buy me beers.

 

Uh huh.

 

Debbie.codes is my website. You can find everything there and all links to, you know, my GitHub. Cause we're on View and View, Views on View. My website is in next three. I updated it recently and I have a whole blog post on my painful journey of all the pain I had to go through to get there so that you don't have to go through that pain. And also my website is open source. You can go to GitHub, clone it. Make your own copy of it, do your own things, use this next content, write your own blog posts, of course, you know, don't use mine, but yeah, use the whole, everything to kind of like be able to fetch that data and, you know, create your own sites. If you're starting out, you wanna have a website up and running, my website is your website, go for it, take it, it's open source, it's all yours.

 

Lots of open source goodies. Alrighty, with that we will wrap up. I'd like to say thank you once again to the studio audience for coming today.

 

Woohoo!

 

They paid

 

And

 

a premium price to be here.

 

my website has tests, just you know, so

 

Hahaha

 

I wanna see everyone's websites have tests for next year. That's everyone's New Year's resolution.

 

Okay, so if you go to her site and find errors, then make sure and send her an email or ping her in the Playwright Discord and say, hey, did

 

Yes.

 

you write a test for this?

 

Exactly. Or just make a PR to my website.

 

Oh, there you go. There you go. Alrighty, well, thanks everybody for listening. I hope you enjoyed hearing more about Playwright, and we will talk at you next time on Views on View.

 

Thank you very much, bye!