Speaker 1: How'd you like to listen to dot NetRocks with no ads? Easy?
Speaker 1: Become a patron For just five dollars a month you
Speaker 1: get access to a private RSS feed where all the
Speaker 1: shows have no ads. Twenty dollars a month will get
Speaker 1: you that and a special dot NetRocks patron mug. Sign
Speaker 1: up now at Patreon dot dot NetRocks dot com. Hey,
Speaker 1: Carl and Richard here with your twenty twenty four NDC schedule.
Speaker 2: Will be at as many NDC conferences as possible this year,
Speaker 2: and you should consider attending no matter what. The Copenhagen
Speaker 2: Developers Festival happens August twenty sixth through the thirtieth. Tickets
Speaker 2: at Cphdevfest dot com.
Speaker 1: Ndcporto is happening October fourteenth through the eighteenth. The early
Speaker 1: bird discount ends June fourteenth. Tickets at Ndcporto dot com.
Speaker 3: And we'll see you there, we hope.
Speaker 1: Hey, guess what it's Dot need rocks again. I'm Carl Franklin,
Speaker 1: that Richard Campbell here for the nineteen hundredth and seventeenth time.
Speaker 2: It's World War One. It's World War one. It it's
Speaker 2: officially started. Okay, we're well into it at this point.
Speaker 1: Yeah, you're right, yeah, yeah, right, So yeah, what's up
Speaker 1: with you, mister Campbell. We just got back from Dev Intersection.
Speaker 1: Had a great time there. Yeah, I had a great
Speaker 1: time there. I was just writing up some of the pieces,
Speaker 1: the keynotes and things. I mean, it's a crazy time, right,
Speaker 1: Like the software is moving fast. Some of the demos
Speaker 1: were astonishing. You had a good workshop, You're real happy
Speaker 1: with it, very happy. Yeah, it's like thirty people in
Speaker 1: it or something, and all about Blazer. Jeff Fritz did
Speaker 1: a sort of an intro to Blazer workshop, and I
Speaker 1: did a more more intermediate advanced workshop, and I also
Speaker 1: had a talk called Gotcha's in Blazer Web Apps and
Speaker 1: not at eight because there are some gotcha's. There are
Speaker 1: some things that Microsoft intended to work a certain way
Speaker 1: and then they didn't really work. So things that work around.
Speaker 2: It's not that bleeding edge of technology anymore though. I
Speaker 2: mean you're kind of at V three. Things are sort
Speaker 2: of maturing out, like it's almost a grown up.
Speaker 1: Yeah, And that's kind of why it was surprising that
Speaker 1: we had gotcha's in the first place. But I think
Speaker 1: they took everybody by surprise, not that there aren't workarounds
Speaker 1: for it. But you know, it's not a reason not
Speaker 1: to use Blazer, but you just need to know what
Speaker 1: they are.
Speaker 2: I think you've also got a moving surface around you too.
Speaker 2: I've got the comment I've got will tie you into
Speaker 2: that pretty well. Yeah, because there's things on change in
Speaker 2: all the time.
Speaker 1: And just to do a little plug, I'm also doing
Speaker 1: that Gotcha's talk with on Sean Walker's virtual event on
Speaker 1: October third. I don't have a time yet, but look
Speaker 1: for that. Okay, okay, So let's get into it with
Speaker 1: a little thing. We call it better no a framework.
Speaker 2: Awesome, roll it all right, man?
Speaker 3: What do you got?
Speaker 1: Well, you know, this started out as me sort of
Speaker 1: pointing to little things in the dot net framework. It
Speaker 1: was even before dot net core, and quickly ran out
Speaker 1: of stuff to talk about. So it just turns into
Speaker 1: you know, hey, what caught my interest this week? I'd pointed.
Speaker 2: It was not that quick. There was a period we
Speaker 2: were doing three of these a week, and you went
Speaker 2: through the whole flip and framework.
Speaker 1: Yeah, pretty much. I mean the stuff that the stuff
Speaker 1: that was tricky.
Speaker 2: Yeah, several years worth of content.
Speaker 1: Yeah, you're right. Okay, So I found this event in
Speaker 1: the twenty through the twenty sixth of January coming up here.
Speaker 1: It's called Global Game Jam.
Speaker 2: Oh, that sounds fun.
Speaker 1: Globalgamejam dot org. And so just like when musicians get
Speaker 1: together and have jam sessions and they feed on each
Speaker 1: other and get creative together and good stuff comes out,
Speaker 1: that's the whole idea with this. It's it's there's sort
Speaker 1: of like four hundred and thirty nine thousand jammers. Wow,
Speaker 1: this is to date, eighty nine thousand games created, one
Speaker 1: hundred and thirty two countries participated. So it's it's all
Speaker 1: online of course, and they have a discord and a
Speaker 1: Twitch stream, and they have videos from last year keynote.
Speaker 1: It's just it looks like a lot of fun. And
Speaker 1: the thing is too that it's not just for gamers
Speaker 1: who you know, who have experience like this is for
Speaker 1: people who might be just game curious, like they don't
Speaker 1: know how games are created at all.
Speaker 2: And the tooling these days is so good, like, yeah,
Speaker 2: don't need a huge team, you can do it by yourself,
Speaker 2: although I've seen lots of teams of three be very
Speaker 2: successful and make it maybe a mobile game, make a
Speaker 2: web game, like there's a lot of choices right.
Speaker 1: Yeah, so that looks really cool. I might pop in
Speaker 1: and check it out and maybe create some games. Might
Speaker 1: be fun.
Speaker 2: Yeah, that's a good idea.
Speaker 3: Yep.
Speaker 1: So who's talking to us today?
Speaker 2: Richard and Grab a comment of a show eighteen fifteen,
Speaker 2: So about one hundred shows ago with our friend Debbie O'Brien.
Speaker 2: Maybe you heard of her, Yeah, and we were talking
Speaker 2: about play Right. This is back from October in twenty
Speaker 2: two and I got a few good comments on the show,
Speaker 2: but this one was very specific. Admittedly it's over a
Speaker 2: year ago now. This is from Chris Martin. He said,
Speaker 2: just getting into play right and it was great listening
Speaker 2: to the episode of Dot and Rocks on it. I'm
Speaker 2: currently getting this implemented for a Blazer app. What's the
Speaker 2: babe for authenticating with azure ad in our tests? Thanks?
Speaker 2: And Carl responded to this actually back then talking about
Speaker 2: azure ad B two c of through Blazer training include
Speaker 2: a link in the show notes for that particular show.
Speaker 2: Although it's changing, it's been a year.
Speaker 1: Yeah, it's changed and stuff's changed.
Speaker 3: Yeah.
Speaker 1: We went through this period where we were using MSAL,
Speaker 1: the Microsoft Authentication Library right as a way to simplify
Speaker 1: accessing it, and now there's even more stuff that's like
Speaker 1: I haven't even i mean even kept up with it.
Speaker 1: That's how new it is.
Speaker 2: Well, they call it an intra now, and so in
Speaker 2: some ways it's clearly better. I think definitely. My repertoire
Speaker 2: for the show's coming up is a whole conversation about
Speaker 2: managed identity. Yeah, specific And it's one thing to manage
Speaker 2: identity in production. It's another thing to talk about managed
Speaker 2: identity in tests and in the dev cycle. But you've
Speaker 2: heard on the news this whole Microsoft Future Security Initiative
Speaker 2: or Insecure Initiative, and a lot of that has to
Speaker 2: do with undersecured dev resources, demos things like that. So
Speaker 2: Microsoft is pushing hard for their own people to do
Speaker 2: this better.
Speaker 1: Yeah, across all teams.
Speaker 2: Yeah yeah, and to be that's super exciting because they're
Speaker 2: going to knock the snot out of this process, like
Speaker 2: they're going to make it better for their own needs.
Speaker 2: That means it's going to be better for all of us.
Speaker 1: I mean we're talking about people who write white papers,
Speaker 1: who publish examples, who you know, maybe do this stuff
Speaker 1: with three sixty the developer team obviously, Yeah, I know
Speaker 1: I know my friend Jeff Fritz is in that.
Speaker 2: Yep, lots of folks that are buried in it right now.
Speaker 2: And and again it's like there's a there's a feedback
Speaker 2: loop here. Not only should they follow the practices, but
Speaker 2: when the practices are just too awkward to use, they
Speaker 2: know where those guys live, Like they'll lay in wait
Speaker 2: in the bushes outside of the office building.
Speaker 1: They'll tackle too soon, too soon.
Speaker 2: No, No, I'm just saying, like I watched what happened
Speaker 2: to WPF back in the day when the studio team
Speaker 2: started implementing WPF, WPF got dramatically better, and it was
Speaker 2: that back and forth.
Speaker 1: Hey, if you want to go way back when sql
Speaker 1: server implemented the dot Net framework inside SQL servert got
Speaker 1: better well, without a doubt, because the sequel team kicked
Speaker 1: its butt.
Speaker 2: Yeah, no doubt. So anyway, I'm hopeful. Yeah, and Chris,
Speaker 2: thank you so much for your commented. A copy of
Speaker 2: music Cobe is on its way to you. And if
Speaker 2: you'd like a copy of music code by I write
Speaker 2: a comment on the website at dot at rocks dot
Speaker 2: com or on Facebook. We publish every show there and
Speaker 2: if you comment there in a reason the show. We'll
Speaker 2: send you a copy music cope.
Speaker 1: He's code by still going strong and people using it
Speaker 1: every day to be more productive when they code or
Speaker 1: sleep or relax or focus or whatever. All right, so
Speaker 1: let's bring in Wi O'Brien. Before I do that, though,
Speaker 1: I need to mention that you can follow us on Twitter,
Speaker 1: and of course we've been on ex Twitter for years.
Speaker 1: But the cool kids are hanging out at Masdon. I'm
Speaker 1: Carl Franklin at tech Hub dot Social.
Speaker 2: And I'm Riche Campbell at Masidon dot Angele.
Speaker 1: Okay, so Debbie has been on the show before, of course,
Speaker 1: but if you don't remember, Wi O'Brien is a Principal
Speaker 1: program manager at Microsoft. Wie has over fifteen years of
Speaker 1: experience in front end development. She's worked as a tech
Speaker 1: lead and consultant for many important and clients with various
Speaker 1: technologies and often with a strong focus on performance, static
Speaker 1: sites and testing. She has led teams both in house
Speaker 1: and remotely, as well as giving workshops and training. Also
Speaker 1: has many years of experience as a mentor for online
Speaker 1: learning platforms, Treehouse and open classrooms. Debbie's also a Google
Speaker 1: developer expert in web technologies, cloud andary Media Developer Expert
Speaker 1: and next Ambassador. Boy, there's a mouthful, as well as
Speaker 1: a GitHub Star alumni and a previous Microsoft Most Valuable
Speaker 1: Professional and Developer Technologies Debbie, I think you need to
Speaker 1: be a little more What should we say, you know,
Speaker 1: just try try a little harder.
Speaker 4: I think I know, right, I'm trying to get the
Speaker 4: YouTube Award. That's my next one, you know that like
Speaker 4: big thing on one hundred thousand followers. I've got five thousand,
Speaker 4: so got a long way to go. But yeah, I
Speaker 4: need more awards.
Speaker 2: Yeah.
Speaker 1: I tell people the kind of the same way. I
Speaker 1: just don't know what I want to do when I
Speaker 1: grow up. I certainly haven't grown up yet.
Speaker 2: Why start now?
Speaker 1: Why start now? Yes, we're talking about Playwright, and Playwright
Speaker 1: is sort of the canonical web testing and automation actually
Speaker 1: platform that does snapshot testing, like we talked about with
Speaker 1: our friend Simon Crop, and it does all sorts of
Speaker 1: other things. Why don't you tell us what's on your
Speaker 1: mind in terms of Playwright?
Speaker 4: Yeah? So, I mean everyone should already at this stage
Speaker 4: be testing their applications, because there's absolutely no excuse in
Speaker 4: the whole world why people are not testing right. Go
Speaker 4: back a couple of years, like ten years ago, no
Speaker 4: one was testing, and I completely understood that because testing
Speaker 4: was hard. Testing to time testing, the slow testing costs money.
Speaker 4: And now it's the opposite. If you're not testing your application,
Speaker 4: you're losing money as a company. You're dealing with bugs
Speaker 4: that you should and even have to deal with. So yeah,
Speaker 4: I've been trying to get people to test their applications
Speaker 4: and I think still there's people not testing. I don't
Speaker 4: know how to fix Carl Richard, how do we fix this?
Speaker 1: I think most people assume and I'm going to assume
Speaker 1: that they assume that, well, why should I test? Because
Speaker 1: I know this routine or this method or creates this
Speaker 1: UI result. Why do I need to prove it? Right now?
Speaker 1: I can see that it works. But the question is, well,
Speaker 1: how will you know when some other developer takes over
Speaker 1: your project and does something on the back end that
Speaker 1: changes the outcome? That's when testing becomes really valuable, right, yeah.
Speaker 4: And just changing like little like think about forms, right,
Speaker 4: Forms are one of the hardest things to test manually.
Speaker 4: And I don't know if you've ever done this a
Speaker 4: manual test and you start manually and what I mean
Speaker 4: by manual is going to the computer's a user and
Speaker 4: filling it that form and then you find out the
Speaker 4: typical For me, it happened to me today. I was
Speaker 4: putting my name in. I have an apostrophe in my name. Well,
Speaker 4: nobody tested the web and I couldn't put a specific
Speaker 4: type of apostrophe in. It wasn't accepting it, so it
Speaker 4: wouldn't accept my name, right, And nobody tested that, so
Speaker 4: I couldn't. I couldn't just couldn't get in. I had
Speaker 4: to like go to the actual computer. I couldn't do
Speaker 4: it for my phone, had to go to the computer
Speaker 4: where I had had more access. I was able to
Speaker 4: do it. But when you're actually testing that out manually,
Speaker 4: you're filling in all those things and then you press
Speaker 4: submit and you get this error message and then something
Speaker 4: is broken, and then you go in and you fix it,
Speaker 4: and then you go and fill that it again, and
Speaker 4: you keep doing that process, a repetible, horrible process that
Speaker 4: I used to do, that you used to do back
Speaker 4: in the old days, when you know, that was the
Speaker 4: only way we could do things. But now you have
Speaker 4: tools such as Playwright that basically is an extremely fast
Speaker 4: you right, it is you times one hundred and that
Speaker 4: can fill that form in one hundred times faster. So
Speaker 4: that basically is automated. Once you write that test, that
Speaker 4: form is filled in. And this is the cool thing
Speaker 4: that you basically to that test. You just manually fill
Speaker 4: in that form once and you do that by using
Speaker 4: the code generator tool. You code gen the test by
Speaker 4: filling in that form, it's going to generate all that
Speaker 4: code for you, and then you just basically press play,
Speaker 4: press play and on your CI it just runs anytime
Speaker 4: the pull request is done in so if someone changes anything,
Speaker 4: it's going to run that and it saves so much
Speaker 4: time and it's so easy and quick to do it. Yeah.
Speaker 1: So the thing that occurs to me about web testing
Speaker 1: tools like Playwright is that they have an advantage because
Speaker 1: they can inspect the HTML, which is just text. You know,
Speaker 1: they can inspect the output, whereas if you're trying to
Speaker 1: do that, say on a Windows forms application or graphical application,
Speaker 1: you have to do image you know, ocr for the
Speaker 1: for the text and image processing and all of that
Speaker 1: kind of stuff, and we just don't need to do
Speaker 1: that with you get. You can still do screenshot testing, right.
Speaker 1: You can say well, the screen should look like this,
Speaker 1: but you have that the webliner allows you to be
Speaker 1: a lot more accurate.
Speaker 4: It brings it closer to the user. And what we're
Speaker 4: doing when we're testing Blaser applications, right, we're testing what
Speaker 4: the user sees, what the user does. Simple thing is
Speaker 4: testing dark mode and lightmode. This is the cool thing
Speaker 4: right nowadays everyone has to have their website in two colors, right,
Speaker 4: how can we test that? Well, we can test that
Speaker 4: the CSS class is there and that can be done
Speaker 4: true playwright, and then you can just easily have a test. Yeah,
Speaker 4: that's dark mode, light moode. That's a simple test.
Speaker 3: Right.
Speaker 4: You do you care? Well, maybe you should if that's
Speaker 4: important to you. What's more important is, you know, filling
Speaker 4: out the forms, making money, putting articles in a shopping car,
Speaker 4: actually purchasing things, and that's what the user does. What
Speaker 4: buttons does the user need to press to get to
Speaker 4: that payment? And if you can test that whole process
Speaker 4: from that start to finish, the money is going to
Speaker 4: be in your bank.
Speaker 2: Yeah. Well, I mean lots of friction you can remove
Speaker 2: in that process. And turns out if it's easy to buy,
Speaker 2: people do buy more. So you know there's money to
Speaker 2: be made in creating good workflows that way, right. I
Speaker 2: just think these are the tools that help you detect
Speaker 2: where you're stumbling before you push it out there and
Speaker 2: start losing money on it.
Speaker 1: Now. I use a tool called b unit from Egil
Speaker 1: Hanson for Blazer components. Does that work in concert with playwright?
Speaker 1: Is there something that does what b unit does in Playwright?
Speaker 1: What's the whole ecosystem look like with that?
Speaker 4: So for component testing itself, we don't really support anything
Speaker 4: outside of the experimental, which is kind of you and
Speaker 4: like the component testing yourself. I'm not sure if you
Speaker 4: can put a Blazer thing inside of vat application that's
Speaker 4: something and push that up. That's something I've never tested out.
Speaker 4: But we're basically like, when it comes to a Blazer,
Speaker 4: you're testing what the user sees. That's already compiled, that's there,
Speaker 4: it's visual, it's on that front end. So you're coponents
Speaker 4: are making up a web page. Your components are making
Speaker 4: a story, and that story is taking you. It's more
Speaker 4: about the integration between those components. Sure, how they integrate
Speaker 4: together and when on the page they do what they're
Speaker 4: meant to do. That button is a component. For example,
Speaker 4: that shopping cart is a component, and that all interacts
Speaker 4: together to be able to get to that stage of
Speaker 4: filling out the form, to fill in your delivery address
Speaker 4: to get the product delivered to your home, etc.
Speaker 1: So you can still a b unit test to test
Speaker 1: the individual components if you think you need to. But
Speaker 1: what you're saying is playwright works the macro level. It
Speaker 1: just works at the whole website. You fill in this form,
Speaker 1: you expect this result. If you don't get it, then
Speaker 1: the test breaks.
Speaker 4: Yeah, Like think about it. The user doesn't care about
Speaker 4: your code, doesn't see your code. So unit tests is
Speaker 4: not covering what the user sees and does. It covers
Speaker 4: your code and is your code going to do the
Speaker 4: job right? But end to end test integation tests, they're
Speaker 4: covering what the use physically does in your website. And
Speaker 4: it's like manual testing years ago when I used to
Speaker 4: do this on a Friday right in a job ten
Speaker 4: years ago. Everyone stop, stop we are doing and start
Speaker 4: using the website as a user would use it. Go
Speaker 4: and start doing stuff right and then fill out issues.
Speaker 4: Oh this doesn't work, file boog, this doesn't work. File
Speaker 4: a bug. That's ridiculous doing that nowadays, and still people
Speaker 4: are doing that. Still people are paying manual people to
Speaker 4: press buttons, and that should not be happening. So Playwright
Speaker 4: is that manual person pressing the button. But that's much
Speaker 4: faster than that manual, physical person that would have done
Speaker 4: that ten years ago.
Speaker 2: One of the things I run into when we start
Speaker 2: to build bigger websites is we have so many tests
Speaker 2: that it slows down the CICD pipeline. I've gone to
Speaker 2: great lengths to like break tests out across ponstible instances
Speaker 2: and things to try and shorten that time up. Is
Speaker 2: there tools in play right to make that easier.
Speaker 4: Yeah, so's there's things you can do. Like basically, you've
Speaker 4: got to remember what's the slowest thing about testing when
Speaker 4: it comes to to Playwright, it's the brows right, It's
Speaker 4: it's you know, you're normally you should be testing as
Speaker 4: well your website across multiple browsers, you know, across the
Speaker 4: fire across Firefox, across Chromium. And once you're doing that,
Speaker 4: you're spinning up that headless browser. Right. There's headless means
Speaker 4: that there's no visual parts, there's no graphical interface, so
Speaker 4: on CI you don't need to see something. The CI
Speaker 4: basically spins up the browser without the actual graphical interface,
Speaker 4: but it's still spinning up a browser instance for your tests.
Speaker 4: And tests are running isolation, right, so that means you
Speaker 4: know there's a new browser instance being spun up every
Speaker 4: time there's a new test, because otherwise, you know your
Speaker 4: cookies would jump from the same if it was the
Speaker 4: same browser, right, and then you can messs of your
Speaker 4: test you have flaky tests, you'd go crazy. So when
Speaker 4: you have like a lot of tests, you're spinning up
Speaker 4: all these browser things. You can do a couple of things, right.
Speaker 4: You can go charting shot across multiple machines, which can
Speaker 4: be good and can be bad depending on how you
Speaker 4: set it up. Because if you shard too much, remember
Speaker 4: you've still got to download the browsers for that shard, right,
Speaker 4: So if you have eight shards, there's eight times you're
Speaker 4: going to do that. Are you saving time or are you?
Speaker 4: So sometimes you have to decide how many shards do
Speaker 4: I need and you've got to play around with those numbers. Now,
Speaker 4: another cool thing, cool thing that we have is the
Speaker 4: Microsoft Playright service, which is not the open source part
Speaker 4: of Playwright but the Azure part. So if you're in Azure,
Speaker 4: you can basically use cloud based browsers. So now the
Speaker 4: browsers that you normally are like downloading are in the cloud.
Speaker 4: And I know it's like we all talk about the
Speaker 4: cloud and we have to imagine this physical cloud and
Speaker 4: the browsers are up there, and you're basically sending your
Speaker 4: tests up to this cloud so it doesn't need to
Speaker 4: download anything. What that means is you're just running your
Speaker 4: tests and you're not doing the browser instance part, which
Speaker 4: saves a hell of a lot of time. Now, obviously
Speaker 4: this is an Azure feature, so it's it's costs money,
Speaker 4: of course, but you save my in the long run.
Speaker 4: If you're talking about scaling at an enterprise level, you're
Speaker 4: talking about large scale. You want to run I don't know,
Speaker 4: ten thousand tests and your pipeline is being slowed down
Speaker 4: forty five minutes is taken. You want to take it
Speaker 4: down to three minutes. You know, any company would pay for.
Speaker 2: That, right, you know, if I'm running tests in the cloud,
Speaker 2: I'm paying for that. So the fact that you've made
Speaker 2: me a dedicated service for this purpose, that sounds good
Speaker 2: to me. That's just going to make fewer mistakes.
Speaker 1: Is that ratio like forty five minutes turns to three
Speaker 1: minutes typical.
Speaker 4: No, that's just me making up a number from the
Speaker 4: top of my head, because obviously everyone's tests are different
Speaker 4: and you'd have to test it out. But the amount
Speaker 4: of time saving across all the examples that we've kind
Speaker 4: of run it on and then the clients that are
Speaker 4: using it in the feedback they've been given us is
Speaker 4: the amount of time. No one is the same, right,
Speaker 4: but everyone has saved immense amount of time. And then
Speaker 4: also what's really important to a lot of people as
Speaker 4: well is being able to see, like, you know, to
Speaker 4: see those those tests in a kind of like a
Speaker 4: dashboard style, to be able to go back and forward
Speaker 4: and then like have a report, right and see a
Speaker 4: report of like this is what happened, this is where
Speaker 4: it failed, and have a trace of that test on
Speaker 4: your you know CEE I, on your on the on
Speaker 4: in the cloud, so that basically you don't have to
Speaker 4: you know, go to local and locally spin up that
Speaker 4: that trace file and then debug it. You can basically
Speaker 4: almost debugget in the cloud.
Speaker 1: Right.
Speaker 4: But yeah, so scaleability was an issue, and we solve
Speaker 4: that issue because we also need to solve that issue
Speaker 4: because otherwise we're losing time.
Speaker 1: That's great news.
Speaker 2: So testing as a service is that where we're going.
Speaker 4: I think we just need to fix testing in general.
Speaker 4: And I'll be very truthful, we do not have it
Speaker 4: all figured out in Microsoft. We're still learning because we
Speaker 4: are so many people, so many teams. We're like so
Speaker 4: many mini companies if you if you kind of think
Speaker 4: about it that way, and everyone is trying to like,
Speaker 4: you know, deliver products. Right, We've got a lot of products, right,
Speaker 4: how do we test all these and how do we
Speaker 4: create a better solution across Microsoft? And then how do
Speaker 4: we let you all use that solution because if we
Speaker 4: just test it into in ourselves, we don't get the
Speaker 4: value from like, oh but what about this feature and
Speaker 4: we need this so, you know, making sure that Playwright
Speaker 4: is open source and then having those other services for
Speaker 4: the enterprise scale really helps us to make a better product.
Speaker 4: But yeah, we're not saying that we have everything sold
Speaker 4: in Microsoft and we know everything. No, we're building things
Speaker 4: as we go along, and we require like the Playwright
Speaker 4: service is going to the reporting is in basically GA
Speaker 4: this week, Right, It's like literally, it's new, so we
Speaker 4: don't have it all figured out because someone might come
Speaker 4: along and say, oh, we want this feature, Well cool,
Speaker 4: tell us let us know. We'll build that feature for you,
Speaker 4: because we might also think that feature is necessary for
Speaker 4: other people. But yeah, everything is being built around making
Speaker 4: lives easier, making testing easier. I think easier is our
Speaker 4: big word here. Easier and getting more people to test.
Speaker 2: Yeah. Absolutely, And I could see it's still in preview too,
Speaker 2: So it's just a hint that you know, you're all
Speaker 2: learning by how people use it and what it's for.
Speaker 2: But I appreciate the idea that you know, this is
Speaker 2: the same angle as why would I build a bunch
Speaker 2: of virtual machines if I can use an app service?
Speaker 2: Why would I, you know, deploy my own caching if
Speaker 2: I could use a reddish cash service like you go
Speaker 2: as far up the stack as he can. That's cool,
Speaker 2: that's I'm excited to see that, just because yeah, I
Speaker 2: don't want to build these things. I'd like you to
Speaker 2: do it for me please and charge me by the
Speaker 2: test exactly.
Speaker 4: And I think if you have that many tests and
Speaker 4: you're you're paying for that means you know you've got
Speaker 4: some good coverage going on there that it's worth paying for, right,
Speaker 4: it was just made.
Speaker 2: Too many pages, you know, Yeah?
Speaker 4: Maybe maybe.
Speaker 2: Well, I mean it's been two years as you were
Speaker 2: on more or less, so it's lead to see Playwright
Speaker 2: continuing do evolve Like that's cool.
Speaker 1: Yeah, so you have a special love for JavaScript frameworks.
Speaker 1: How does Yeah, that's writing your bio. I'm not hating, Nana,
Speaker 1: I'm just reading here, reading your bio. So how does
Speaker 1: a JavaScript play into Playwright? If at all is any JavaScript?
Speaker 1: Are there entry points for JavaScript in Playwright? If you
Speaker 1: want to do some custom things? How does you know?
Speaker 1: That's the question, I guess.
Speaker 4: I think what's important to understand about Playwright is that
Speaker 4: it can be used across four languages. Right, So if
Speaker 4: you were like myself, I'm a JavaScript developer or typescript
Speaker 4: developer now is what the cool kids say, then I
Speaker 4: can basically use that language because that's what I'm familiar with,
Speaker 4: That's what my website is built in. So I'm naturally
Speaker 4: going to write my tests using the language that I know.
Speaker 4: But Carlin Richard, you're dot net people, right, and you
Speaker 4: you're c sharp probably better than JavaScript, and your website
Speaker 4: is probably built in Blazer, so you're gonna want to
Speaker 4: write your tests in c sharp and not in JavaScript.
Speaker 4: And I totally understand that. And that's why Playwright is
Speaker 4: so cool because you can just do that, because you
Speaker 4: can use Playwright as a dot net developer. And I
Speaker 4: know this is dot net rocks, but let's talk about
Speaker 4: the Java people and the Pithon people because they can
Speaker 4: also write tests using Python and using Java and it's
Speaker 4: the same API, and you don't have to learn new tricks,
Speaker 4: and you know, you can have one company, which we do.
Speaker 4: We're like in Microsoft, we have like you know, various
Speaker 4: and we're using different languages depending on the teams and
Speaker 4: depending on what we're testing and what people are comfortable with.
Speaker 4: So we use dot Net, use Pithon, we use Java,
Speaker 4: we use JavaScript. There are differences, of course, right, I'm
Speaker 4: not going to lie and say it's the same across
Speaker 4: the board. It can't be the same across the board
Speaker 4: for various reasons. Because test runners MS test, you can't
Speaker 4: compare the MS test to the pie test for example,
Speaker 4: they have different stuff, right, And in JavaScript, we built
Speaker 4: the test runner and play right, so it's a little
Speaker 4: bit different. We've got a little bit more leeway on,
Speaker 4: you know, doing certain things.
Speaker 1: And I just want to say for the record that
Speaker 1: some of our best friends, right, JavaScript, Python and Java. Okay,
Speaker 1: so isn't that what they say usually when somebody uses
Speaker 1: you of anti say that some of our best friends.
Speaker 2: But either way, you are testing a web app, you're
Speaker 2: just able to write the code for the test in
Speaker 2: c sharp.
Speaker 1: Yeah.
Speaker 4: Yeah, because playwright just sees like what's out on the website, right,
Speaker 4: what's what's being produced? The what the you know you
Speaker 4: inspect code, right, and so you can see what the
Speaker 4: user can see that accessibility role, right. It just sees
Speaker 4: that that is a role of a button, and it's
Speaker 4: looking for what a screen reader would read out or
Speaker 4: what a user would see. You sees a button and
Speaker 4: it clicks that button, and it does not care if
Speaker 4: your button is written in blazer React you write heighten whatever.
Speaker 2: Yeah, no, and right, you know you don't want to
Speaker 2: make writing the test the barrier, exactly like you wanted
Speaker 2: to be as easy as possible. So I appreciate that
Speaker 2: writing the language you want. I could write tests in Python.
Speaker 2: That's one way to slow myself way down.
Speaker 4: It could be fun there. You might learn something, maybe.
Speaker 2: It's interesting you think about writing in different languages for
Speaker 2: different tasks.
Speaker 1: Yeah, okay, that's cool. So break time. Want to take
Speaker 1: a break.
Speaker 2: Let's take a little break.
Speaker 1: All right, We'll be right back after these very important messages.
Speaker 1: Did you know you can easily migrate asp net web
Speaker 1: apps to Windows containers on Aws. Use the app to
Speaker 1: Container tool to containerize your iis websites and deploy to
Speaker 1: AWS managed container services with or without Kubernetes. Find out
Speaker 1: more about app to Container at aws, dot Amazon dot com, Slash,
Speaker 1: dot Net, slash modernize, Attention dot netdeville. Looking for the
Speaker 1: ultimate SDK to handle electronic document processing? Meet tx text Control.
Speaker 1: Txtext controls your go to solution for seamless PDF generation,
Speaker 1: secure electronic signatures, and efficient digital forms processing all within
Speaker 1: your dot net applications. Empower your products with robust document
Speaker 1: management capabilities, boost productivity, and deliver top notch solutions to
Speaker 1: your clients. Trusted by developers worldwide, including me and Richard,
Speaker 1: txtext control is the SDK that makes a difference. Check
Speaker 1: out demos dot textcontrol dot com for live online demos
Speaker 1: and see it in action. And we're back dot NetRocks on.
Speaker 1: Carl Franklin. That's my buddy Richard Campbell and our friend
Speaker 1: w O'Brien. We're talking about testing with playwright and just
Speaker 1: a reminder that if you don't like those ads and
Speaker 1: you don't want them, you can pay five bucks a
Speaker 1: month and be a patron and you can get a
Speaker 1: feed with ad free shows. All right, So we were
Speaker 1: talking about we're talking about all sorts of stuff and
Speaker 1: testing in different languages. But snapshot testing is something that
Speaker 1: I learned about from Simon Crop. And so the idea
Speaker 1: is that you have you have these following inputs and
Speaker 1: you expect the following output and I get is that
Speaker 1: primarily how playwright works or is it even simpler than that?
Speaker 4: So it's just another part of something playwright can do. Right,
Speaker 4: So snapshots is like, you know, you're testing that something
Speaker 4: looks the same that for example, this is really good
Speaker 4: for Wednesday, like those banners up here at the top
Speaker 4: of your you know, the Black Friday banners that appear,
Speaker 4: and then what I like is there and you want
Speaker 4: it to be there, but you wanted to, I don't know,
Speaker 4: make sure it's not there after Black Friday eatin doesn't
Speaker 4: make sense. So you could, like you know, write a
Speaker 4: test that then I don't know, shows the banner, and
Speaker 4: then make sure that it is exactly the same as
Speaker 4: a banner right on the website. But yeah, there's a
Speaker 4: lot of people using snapshot testing or visual regression testing
Speaker 4: as a whole ballgame. It's not easy, right because because
Speaker 4: across browser as well, the slight little differences, so you've
Speaker 4: got to, like, you know, also make sure your pixel
Speaker 4: differences are kind of the same, because Safari will do
Speaker 4: something a little bit different to Firefox because that's just
Speaker 4: how they do things. But definitely, I think if people
Speaker 4: are getting started with testing, I wouldn't say, go and
Speaker 4: make sure your website looks exactly the same as the
Speaker 4: snapshots like everything, because you'll end up possibly things will
Speaker 4: fail if you change that button. You've got to re
Speaker 4: recreate those snapshots each time. So I would always say, like,
Speaker 4: that's an extra, that's great and it's cool, but first
Speaker 4: make sure that your user can do what the user
Speaker 4: should be doing. Whatever it is on that website is
Speaker 4: going to bring you money or make you click that
Speaker 4: patron button that you talked about, whatever it is, test that.
Speaker 4: Then do the accessibility testing, the regression testing, the API testing,
Speaker 4: there's a whole ballgame of things that you can.
Speaker 2: Explore, sure, right, but I mean the snapshot test is
Speaker 2: really about a look and feel thing rather than a
Speaker 2: functionality thing.
Speaker 4: Yeah, it's about that it looks the same basically that
Speaker 4: it hasn't changed that the designer didn't put a CSS
Speaker 4: hidden on a button and now they can't see the
Speaker 4: button for example. Right, But then if that was the case,
Speaker 4: player wouldn't be able to click the button, so that
Speaker 4: test would fail.
Speaker 2: It would still break anyway, exactly.
Speaker 4: But sometimes there are times when visual aggression testing is
Speaker 4: really important, especially when using I don't know when they say,
Speaker 4: like a lot of advertisements on your website and you
Speaker 4: want to remove those and just see what the website
Speaker 4: looks like out those You can mask those kind of things.
Speaker 2: Well, no websites are so twitchy these days, right, Like
Speaker 2: thank goodness for pie hole. Otherwise there's stuff flying at
Speaker 2: you in all directions.
Speaker 1: And you can also exclude things like you say, I
Speaker 1: want this page to look like such and such with
Speaker 1: the following data that it because we put in a
Speaker 1: certain input. But you know, little things like the date
Speaker 1: in the time, we don't want to We don't care
Speaker 1: about that that can change.
Speaker 2: Yeah, I'm kind of staggered at how it would do
Speaker 2: those visual representations you just talked about sort of headless
Speaker 2: browsing where there is no visual component, but is do
Speaker 2: something different when it wants to create a visualization.
Speaker 4: Well, it's just like taking a photo and then like
Speaker 4: it takes a photo kind I'm just doing like an
Speaker 4: example here, right, you take your phone out and you
Speaker 4: take a photograph of your screen of the website, and
Speaker 4: then you change your code, and then it takes another
Speaker 4: photograph and then it compares those two overlays one in
Speaker 4: front of the other, and it kind of sees like
Speaker 4: is there a pixel difference? Has the button moved over there?
Speaker 4: What's it expecting and where is the button now? And
Speaker 4: I'm using button as an example, but it could be anything, right.
Speaker 2: But it is pixel perfect it.
Speaker 4: Yeah, but you can adjust that, right, You can say
Speaker 4: I want it to be like so many pixels away
Speaker 4: because I don't know it's an animation that's gonna like,
Speaker 4: you know, I don't do stuff, and you know you
Speaker 4: want it to be able to move a little bit
Speaker 4: or whatever.
Speaker 1: So I wasn't really thinking of taking screenshots, screenshot testing,
Speaker 1: snapshot testing something I learned from Simon because he has
Speaker 1: a tool called Verify, and it's really just testing the
Speaker 1: HTML output of a page. So like a form, Right,
Speaker 1: you fill in a form, you press a button, it's
Speaker 1: going to give you a summary of that data. And
Speaker 1: that is what it tests that the output of this
Speaker 1: matches what we expected to match. So I think I
Speaker 1: think we might be talking about two different things.
Speaker 4: We're probably talking about different Yeah.
Speaker 2: But it is that in that case, it is literally
Speaker 2: a text comparison to the HTML. Yeah, Like if I
Speaker 2: was doing visual representation comparison, I could write the page
Speaker 2: different ways but have to present the same way.
Speaker 1: Yep.
Speaker 2: Not that I'm good enough to do that, but you
Speaker 2: know that would be interesting.
Speaker 1: Yeah, you want to make sure that this did with
Speaker 1: this ID has this content right, which is different than
Speaker 1: you know, comparing uh screenshat, which is also valuable. I
Speaker 1: mean absolutely, There's just so many ways to go about testing.
Speaker 2: Yeah, I'm just wondering about the brittleness of tests, right,
Speaker 2: Like most people dive into testing the first round of
Speaker 2: tests they build. The next time they do enough to
Speaker 2: do the app, every single test is broken and they right,
Speaker 2: why did I do this?
Speaker 1: Yep?
Speaker 2: And you Debbie jump in on this, like, how do
Speaker 2: you write non brittle tests?
Speaker 4: I think you just have to constantly test. You've got
Speaker 4: to like make sure that I don't know, I think,
Speaker 4: I think use the tools that are there. I would say,
Speaker 4: use the tools that are the code generator, right, the
Speaker 4: code gen will generate the test view. I think a
Speaker 4: lot of people going back the previous days would have
Speaker 4: wrote their test using things like XPath, using things like
Speaker 4: CSS selectors, right, And that was the right thing to
Speaker 4: do back then. But our front end, and I don't
Speaker 4: know about you guys in the Blazer world, but we
Speaker 4: CHANGEAVASCRIPT are known for We're changing things all the time, right,
Speaker 4: We're constantly like changing, so our htmil is changing. And
Speaker 4: if you're going to change that, the x path is
Speaker 4: going to change, which means your test is now going
Speaker 4: to be brittle. It's going to break just changing your
Speaker 4: CSS class. New developer comes along and he changes a
Speaker 4: CS class. If your website and your tests break, well,
Speaker 4: that's not good, right, So you need to avoid things
Speaker 4: like that. And the way to do that is, you know,
Speaker 4: use the test generator tools to generate those locators. Locators
Speaker 4: is how you locate an element on the page. So
Speaker 4: how do I all locate that button on the page.
Speaker 4: You use a get by roll button, and that button
Speaker 4: has a name called submit, and that is tested. It's
Speaker 4: also tested for accessibility, and it's easier than for you
Speaker 4: to go out and just do whatever you want with
Speaker 4: that button, change the CSS of it, put it in
Speaker 4: a different place. Play right's going to look for that
Speaker 4: button with a roll of button call submit, and it
Speaker 4: doesn't care where it does in your page because that's
Speaker 4: not important. What's important is that the user can click it,
Speaker 4: and the user can get to that next section of
Speaker 4: the page or whatever it needs to do with it.
Speaker 4: So I think making sure you test as close to
Speaker 4: the user as possible will save a lot of problems
Speaker 4: in the long run when it comes to brittle tests.
Speaker 1: M So instead of on Fridays you guys all get
Speaker 1: together and push buttons, now you're getting together and updating
Speaker 1: your tests or maybe you're doing that every time you
Speaker 1: check in something, right, yeah, and make sure your tests
Speaker 1: are working.
Speaker 4: And what's really cool is is like the code Generator
Speaker 4: tool is very cool because you literally like it launches
Speaker 4: up a browser window, right, and you put in your
Speaker 4: website address and you start using a use as a
Speaker 4: user would, and you generate that code, and then you've
Speaker 4: got tools like get up copilot, right, and you can
Speaker 4: do really funky things at copilot because you can turn
Speaker 4: around and then say a test step for my tests,
Speaker 4: and it's going to like literally take the code that
Speaker 4: you've just written, that you've just generated, actually you haven't
Speaker 4: written it, you've just generated, and it's going to put
Speaker 4: it into test steps for you, and it's going to
Speaker 4: do all these kind of other stuff that you want
Speaker 4: to do it or put it into a described block
Speaker 4: or you know, you can help get a copilot can
Speaker 4: also help you to improve the code. So as a developer,
Speaker 4: you're not sitting there just like writing the boring parts
Speaker 4: of testing. You're using the tools to your advantage.
Speaker 2: Mm hmm.
Speaker 1: Good.
Speaker 2: Yeah, And I think definitely I remember in Strange Loop.
Speaker 2: I think the third go around of writing tests for
Speaker 2: Strange Loo, we've gotten better at writing tests that just
Speaker 2: we're going to be more tolerant, like you're still checking
Speaker 2: the value the way you want to, but you're not
Speaker 2: fussing over you know, unnecessary elements of that. That means
Speaker 2: that the slightest change in the test fails. Yeah. I
Speaker 2: think it's really an art to write good tests and
Speaker 2: stuff that will give you check the stuff you need
Speaker 2: to check without being infrastructure where minor changes the things
Speaker 2: just derail all the tests.
Speaker 4: I think that's the difference between unit testing, right, whereas
Speaker 4: unit testing really is so close to the code that
Speaker 4: it's like you change something in the code or your
Speaker 4: test is going to break. With play right, really, you
Speaker 4: can change something in the code and your test shouldn't
Speaker 4: break unless you change, say, like what the user sees
Speaker 4: and instead of a submit button, you put upload, and
Speaker 4: now it's going to like look for submit and it
Speaker 4: finds upload because that they messed up the translation or whatever, or.
Speaker 2: You've removed I or you've removed a field or like you.
Speaker 2: I mean, there's also good test fails where it's like
Speaker 2: I made this change and the test shows that I
Speaker 2: made this change. Now I can remove the test or
Speaker 2: change the test. Yes, I don't mind it when it
Speaker 2: is clear on stuff. What I mind is, hey, you know,
Speaker 2: we wrote three hundred tests around this set of pages,
Speaker 2: and I changed this CSS structure and every test is
Speaker 2: vailing now.
Speaker 4: And that's the difference between unit tests, right, because you
Speaker 4: write that test and then you can't really see what's
Speaker 4: going on, right, you're stuck in code land. But in Playwright,
Speaker 4: when you have that failing test, you spin up a
Speaker 4: trace of your test, and that's like basically be able
Speaker 4: to go think of a video, but better so a
Speaker 4: video with dev tools, a video that you can manually
Speaker 4: step between every single step and go back and forward
Speaker 4: in time at your own pace, and have a DMB
Speaker 4: snapshot that you can just pop out and inspect the
Speaker 4: dev tools and say, right, I know what happened here.
Speaker 4: Somebody puts CSS hidden. I'm just gonna use that example
Speaker 4: because that actually happened to me on one of them
Speaker 4: that I was testing on the podcast website, and it
Speaker 4: put CSS hitting them playright couldn't find it because it
Speaker 4: isn't visible to the user. So if the user can
Speaker 4: click it, but the code is there, the code didn't change.
Speaker 4: The CSS change and the CSOs could have been in
Speaker 4: a different file to the code, right well.
Speaker 2: And so that could have gone the other way. Right,
Speaker 2: you've hid it the test pass and you deploy it,
Speaker 2: but the users can't work that. Yeah, you want to
Speaker 2: be able to catch that too. It's it's it's always
Speaker 2: going to be a battle.
Speaker 1: Can can Playwright penetrate to the level where it can
Speaker 1: see components of the shadow? Don Yeah, it just works.
Speaker 4: It just works, iphrames, it just works.
Speaker 1: Just wow. Not well that was a simple answer.
Speaker 4: Sorry, I try to make it more complicated.
Speaker 1: Yes, no, yes, no question, I can't tell. That's great. Yeah,
Speaker 1: that's great because that that has been a problem.
Speaker 4: In the past, you know it has. That's why we
Speaker 4: had to solve it. Because you know, problems need to
Speaker 4: be solved.
Speaker 1: Yeah.
Speaker 2: Do you find that developers are using playwright in their
Speaker 2: local cycle or is this purely part of the c
Speaker 2: i CD pipeline.
Speaker 4: I think it has to be both, because you need to.
Speaker 4: I always think that unless a website is finished, which
Speaker 4: I've very rarely seen, what is product finished exactly exactly,
Speaker 4: So unless it's something that you are never going to
Speaker 4: touch ever again in your life and you're going to
Speaker 4: write those tests and it's just on CICD for whatever reason.
Speaker 4: But no, nothing has ever finished. Things are always changing.
Speaker 4: So running your tests locally as you're building some code,
Speaker 4: as you're adding additions, as you're changing things always makes sense.
Speaker 4: Some people don't. Some people push it to CEICD so
Speaker 4: they can just get their code up there and they're
Speaker 4: not testing it locally, and then like you know, Friday,
Speaker 4: they make all the changes, they push and then they
Speaker 4: can't go home because, like you know, something broke. So
Speaker 4: running it locally always always helps, and having the tools
Speaker 4: like it's it's when when tests are quick and easy
Speaker 4: to run, it means people don't mind running them locally.
Speaker 4: When tests, if your test takes forty five minutes to run,
Speaker 4: as a developer, I'm not going to run it. I'm
Speaker 4: not going to run it locally. I might run the
Speaker 4: one test that I'm working on, but it might affect
Speaker 4: other things the code I'm working on.
Speaker 2: So and that's sort of that integration test that after
Speaker 2: the fact. Yeah, now you go check the integration effects.
Speaker 4: So I always say, like new code you're building, I'm
Speaker 4: building this new feature, then I really want to work
Speaker 4: on those tests. I'm writing those tests. As I'm building
Speaker 4: the feature. I write the tests, and then I'm testing
Speaker 4: that and then I you know, it's now deployed and
Speaker 4: then it's running on CICD and it keeps running. Yeah,
Speaker 4: So it's a mixture of things.
Speaker 2: I mean, a CICD part is not not optional. Before
Speaker 2: this heads towards deployment or load testing or the next stage.
Speaker 2: It must be thoroughly tested. It's just a question of
Speaker 2: how much of that can you pull down to the
Speaker 2: local workstation for that DEV cycle, the impacts that would
Speaker 2: have on them. I guess it would be great to
Speaker 2: organize it in such a way that you could only
Speaker 2: need to test the piece you're working it.
Speaker 1: Are there any common misassumptions or barriers to entry or
Speaker 1: gotcha's that people will find misassumptions, Maybe that people will
Speaker 1: run into things that they assume that it does that
Speaker 1: it doesn't do, or what's the typical getting started barrier
Speaker 1: that you see people having.
Speaker 2: I think that miss assumption is a word. Look, sorry,
Speaker 2: you looked up? I did?
Speaker 1: I can't.
Speaker 2: I just like, what have you met me? You've appreciate
Speaker 2: met me? Debbie, I'm sorry, We're okay.
Speaker 4: So I think what's really important to note is that
Speaker 4: tools change and evolve over time, and things get better
Speaker 4: and we improve things a lot. So sometimes people will
Speaker 4: say I'm going to go write a test and they
Speaker 4: are too. I'm gonna use the word lazy, but it's just,
Speaker 4: you know, that's my word, but there could be another
Speaker 4: way of describing it. They're too lazy to read the documentation.
Speaker 4: So what they do is they just go and they say,
Speaker 4: I'm going to write a test. I don't want to
Speaker 4: read docs. So what do I do? And what do
Speaker 4: we all do? We just Google right and you just
Speaker 4: throw it into Google or now we got the new Google.
Speaker 4: We got chat gtpt right, and we say, how do
Speaker 4: I write a test in Playwright? And some times the
Speaker 4: results we get are wrong and we don't care because
Speaker 4: we don't know because we didn't read the docs. We
Speaker 4: copy and we paste that code and we put it
Speaker 4: into our tests and then we go, my test is breaking,
Speaker 4: and I don't know why my test doesn't work, and
Speaker 4: I don't know.
Speaker 1: What it works when it shouldn't work exactly.
Speaker 4: So this is really important to kind of make sure
Speaker 4: you're using the latest version that you know, I mean,
Speaker 4: Playwright is you know, the first time Playwright came out
Speaker 4: three years ago, the locators were different to what they
Speaker 4: are now. And you know, sometimes chat GTPT isn't up
Speaker 4: to date, it hasn't been trained in the latest model,
Speaker 4: so it's going to give you an old version.
Speaker 3: Right.
Speaker 4: Someone on stack overflow maybe wrote that a couple of
Speaker 4: years ago. Maybe doesn't know much about testing. You have
Speaker 4: no idea of their knowledge level. You're just copying their
Speaker 4: code and their answer, assuming that they're all experts and
Speaker 4: that you're not an expert. But really, if you just
Speaker 4: go into the documentation and did the same search and
Speaker 4: the documentation, you would get that answer. We get a
Speaker 4: better answer.
Speaker 1: Are there are there really good examples in the documentation
Speaker 1: of you know, for people getting started their walkthroughs or
Speaker 1: that kind of thing.
Speaker 4: So I'm going to be very very honest and tell
Speaker 4: you that I did never basically ever install sea sharp
Speaker 4: on my computer until literally a couple of months ago.
Speaker 4: Of all guils, I built the getting started docs for
Speaker 4: c sharp, and I took it from start to finish,
Speaker 4: and I mean from start to installing on my computer.
Speaker 1: Wow.
Speaker 4: So if I, as a non developer, can write a
Speaker 4: playwright test in dot net by following the getting started guide,
Speaker 4: then a dot net developer should be able to do
Speaker 4: it ten times faster than me and should be very
Speaker 4: successful in a very short space of time.
Speaker 1: Well done you nice.
Speaker 2: Thanks, Yeah, that's.
Speaker 4: Actually really easy to install.
Speaker 3: Do it?
Speaker 4: I realized it's actually a purple button. You just press
Speaker 4: it and then it just installs. I did not know that.
Speaker 2: Yeah, I mean we always had this problem. But there's
Speaker 2: too many ways and so did some of them are
Speaker 2: hard and yeah, if you picked it.
Speaker 4: You know what I did, I asked chat and you
Speaker 4: know what it did. It sent me down the rum path.
Speaker 1: Oh man, you go to the docks.
Speaker 2: Who's lazy? Yeah?
Speaker 1: Right, it's like have an intelligent mentor that sometimes loses
Speaker 1: its mind.
Speaker 2: Well, it gave you an answer, it just wasn't the
Speaker 2: easiest answer, right, Like, that's that's a tough concept for
Speaker 2: a piece of software to figure out.
Speaker 1: Gott to change your system? Prompted to can you not
Speaker 1: give me any dumb answers? That'd be great. If you
Speaker 1: don't do that, you're only going to get dumb answers.
Speaker 4: I mean the answer sounded good to me if it
Speaker 4: felt familiar in my world. It was like, you know, yeah, homebrew,
Speaker 4: just homebrew it all up. Yeah, that's that's me, Mark
Speaker 4: that that does it. But no, you don't need that
Speaker 4: was it was?
Speaker 2: It was it Hunter that told you. It's like we
Speaker 2: made a button.
Speaker 1: There's a button.
Speaker 4: Yeah, why don't you know about the button?
Speaker 1: One thing that I've noticed as an aside here that
Speaker 1: Chat GPT is terrible at is CSS?
Speaker 2: Oh boy?
Speaker 1: Yeah, don't try to solve a CSS problem with chat GP.
Speaker 2: Problem. Now I have two problems.
Speaker 1: I have a problem factory.
Speaker 2: Yeah, I tried it with Kubernetes and a head of
Speaker 2: container problems. Yeah, CSS is terrible. I'm sorry. Or did
Speaker 2: I have a problem orchestrator. It's one of those, you.
Speaker 1: Know, I might as well ask the JavaScript JavaScript web
Speaker 1: queen here. CSS visualization tools exist so that you can
Speaker 1: see a tree view of your application so you can
Speaker 1: more easily diagnose CSS problems.
Speaker 4: I mean, we just live in death tools, and like
Speaker 4: the death tools is in me, and even like you know.
Speaker 1: You really think so, yeah, you think the dev tools
Speaker 1: are amazing for CSS. I mean, I guess you do
Speaker 1: see the tree, see.
Speaker 4: Everything you see like accessibility for your components. You can
Speaker 4: see the color. You can even like modify it and
Speaker 4: say like that's that a color is not accessible. But
Speaker 4: if I can just like scroll it across a bit,
Speaker 4: this is an accessible color, which means you can go
Speaker 4: back to your designer and say, hey, that gray it's
Speaker 4: just not going to work for me, but if you want,
Speaker 4: can we make it this grey? Because that would work
Speaker 4: accessibility wise, and then they just kind of get you know,
Speaker 4: they love their colors and their stuff, so they go, oh,
Speaker 4: that gray is a little bit different.
Speaker 1: Yeah, I guess what I'm really looking for, And maybe
Speaker 1: the dev tools haven't have just missed this. But you know,
Speaker 1: when you're several layers down, like maybe ten or eleven
Speaker 1: or twelve layers down, and you have some CSS that's
Speaker 1: all messed up and it's not what you expected, can
Speaker 1: you like querry that and say, yeah, where did this
Speaker 1: particular attribute come from in the CSS tree?
Speaker 2: Why is this hidden?
Speaker 1: Yeah? Why is it hidden? Why is it purple? Why
Speaker 1: is it not purple?
Speaker 4: I think a lot of people write very very bad CSS,
Speaker 4: and that is a weird problem that you need to solve,
Speaker 4: and deaf tools can't solve that, and there's no tool
Speaker 4: I can solve that. I tried to solve that in
Speaker 4: a company and I literally re architected the whole thing
Speaker 4: in the amount of times, like CSS, this is being
Speaker 4: used across twenty components and you change it once and
Speaker 4: it's going to affect so many others, but but you
Speaker 4: don't know about it because this file live somewhere else,
Speaker 4: and it's just being cold and bundled together. I mean,
Speaker 4: tailwind kind of solves that a little bit. If you
Speaker 4: wanted to get out on that road, That's what I
Speaker 4: would have used and used.
Speaker 1: Maybe there's a good AI solution out there waiting on
Speaker 1: the horizons that you can just ask, why is the
Speaker 1: button not purple? There you go or whatever, and it'll
Speaker 1: find it in the tree and.
Speaker 4: Bob shrunkle AI is going to solve all our problems.
Speaker 1: All the problems, all the problems I know. Yeah, co
Speaker 1: pilot for CSS. Here it comes you laugh, I bet
Speaker 1: it's coming. Well.
Speaker 2: That brings up a great question, Daddy, what's next for Playwright? Like,
Speaker 2: is how long's your to do list?
Speaker 4: I think the too list is never ending and nobody
Speaker 4: can ever know because like when we last spoke, I
Speaker 4: never knew that, you know, cloud based browsers were going
Speaker 4: to be a thing. That was never because we didn't
Speaker 4: we didn't have that scaling problem. We didn't have that
Speaker 4: many people using Playwright, so we didn't have all this
Speaker 4: feedback from all these people and companies and community. I mean,
Speaker 4: we went from zero members in discord to over thirty
Speaker 4: thousand members since since we spoke, basically right, so all
Speaker 4: of those companies are now using playwrights. You need different solutions,
Speaker 4: so we basically use GitHub. Playwright is open source and
Speaker 4: people file issues and say we have this problem, we
Speaker 4: want this tool, we want this and everything that we
Speaker 4: built is based on up votes from our users and
Speaker 4: you just go to that file an issue and up voted.
Speaker 2: How organized these issues are technically collecting feedback like I
Speaker 2: could see you guys are taking care of this part
Speaker 2: of the inner loop, like because people are asking for features,
Speaker 2: they things they think are bugs but may or may
Speaker 2: not be like mm hmm exactly. So really are developing
Speaker 2: out in the in public. Basically anybody can contribute. Anybody
Speaker 2: can read lots of comments too, like you're clearly prosecuting
Speaker 2: these like what do you think of this? What about that? Way?
Speaker 2: You know, how would we solve it this way?
Speaker 4: Because we have to understand, right, sometimes people say I
Speaker 4: need this feature, like we'll explain to us because I'm
Speaker 4: not seeing what you're seeing, so we need to understand, like,
Speaker 4: you know, what is it that we why do you
Speaker 4: want this? Why is it important?
Speaker 1: Or the question that I'll microsoft people ask, why would
Speaker 1: you ever want to do that? It's it's not a
Speaker 1: threatening question. It's a real question, like why, what's your why?
Speaker 4: Yeah, because then we can say, well, oh that sounds great,
Speaker 4: let's you know, put some time towards that and work
Speaker 4: on that one instead of this feature, right, or fix
Speaker 4: this boog instead of that bog or whatever.
Speaker 2: Yeah, yeah, totally. And I said just and you know,
Speaker 2: you could write the code too, like if you're if
Speaker 2: you're that interested like that, you can contribute.
Speaker 4: We have had we've had some external contributors, especially in
Speaker 4: the last releases, and I think now get up has
Speaker 4: done some really nice thing where you can kind of
Speaker 4: see their names and their picture and it's really cool.
Speaker 4: So that even like is nice, So yeah, do yeah.
Speaker 2: To contribute to a project like this, that would be
Speaker 2: really fun because.
Speaker 4: We are a very small team, so we can't do
Speaker 4: everything that people want us to do because it's just
Speaker 4: not possible, so we can only like say.
Speaker 2: It's a triayeah, yes, I get that. That makes a
Speaker 2: lot of sense.
Speaker 1: Very cool, awesome sense, like a fun project to contribute to.
Speaker 1: If you're looking first, you've.
Speaker 2: Had a lot of contributors. Holy man, look at this list.
Speaker 4: Yeah, hundreds. We have a great community. I told you.
Speaker 4: And Discord Yeah, oh, there you are.
Speaker 2: I see your commit.
Speaker 1: Well, Debbie, it's been an absolute delight having you on
Speaker 1: the show again, and congratulations on playwright success. And we
Speaker 1: hope our listeners will check it out.
Speaker 4: I mean they have to, it's not we hope. You
Speaker 4: got to be strict to Carl, you gotta tell them.
Speaker 1: All right, guys, my next episode.
Speaker 4: You have all should have written at least one test,
Speaker 4: and I want.
Speaker 1: To see some comments on hiver right.
Speaker 4: I would say I would challenge I would challenge anyone
Speaker 4: who thinks or has never written a playwright test. I
Speaker 4: would say take seven minutes. I won't say seven, not
Speaker 4: ten's a little bit more than five. Seven minutes. Go
Speaker 4: to the getting started guide and the documentation of the
Speaker 4: dot net and basically write that test. And you don't
Speaker 4: even have to have a website. Just put in any
Speaker 4: website and just just go through it and write that test.
Speaker 4: Seven minutes and you'll have a test written to your developer.
Speaker 4: You'll get a pay rise in a second.
Speaker 1: All right, there you go. Let's take make this about money,
Speaker 1: all right, Debbie, thanks a.
Speaker 4: Lot again, Thank you.
Speaker 1: All right, we'll talk to you next time on dot
Speaker 1: net rocks. Dot net rocks is brought to you by
Speaker 1: Franklin's Net and produced by Pop Studios, a full service audio,
Speaker 1: video and post production facilities located physically in New London, Connecticut,
Speaker 1: and of course in the cloud online at pwop dot com.
Speaker 1: Visit our website at d O T N E t
Speaker 1: R O c k S dot com for RSS feeds, downloads,
Speaker 1: mobile apps, comments, and access to the full archives going
Speaker 1: back the show number one recorded in September two thousand
Speaker 1: and two. And make sure you check out our sponsors.
Speaker 1: They keep us in business. Now go write some code.
Speaker 1: See you next time you got jas middle Vans
Speaker 3: Home the