Check out a free preview of the full Enterprise UI Development: Testing & Code Quality course

The "Playwright Setup" Lesson is part of the full, Enterprise UI Development: Testing & Code Quality course featured in this preview video. Here's what you'd learn in this lesson:

Steve clones a new repo and installs Playwright. The Playwright tests will run in multiple browser environments and provide test summary reports for each. The Playwright VSCode extension is also introduced in this lesson.


Transcript from the "Playwright Setup" Lesson

>> We have a second repo for this. Purposely these are not built in React, these are built in Svelte, mostly to point, this should not be a framework specific course, despite my case study on my own Redux issue earlier. But there's a bunch of just apps where we can drive it on cuz theoretically, your user does not care whether or not using Svelte or Vue, or Angular, or Backbone, or jQuery, or React or what have you.

They're going to a website, half the Internet is probably still WordPress and jQuery to be honest, despite what you read on Hacker News. And so you can go, and so one of the ways unique to our interest in this workshop, where I would say that this is a really great option is, if you're doing every few year framework switch, right?

That never actually happens, you're always about to do it, and then you end up like three React pages and a Backbone app. And so this is a great way to kind of build yourself the infrastructure to begin figuring that out, and moving stuff and doing the large refactor, and stuff along those lines.

Ideally, unless I have made some terrible mistakes, which I might have, we can set up Playwright using npx, let me just check it out real quick. So you got this, basically, what it will do is it will pull down all the browsers. So, we will go ahead and we will get started here.

How to install Playwright? Npm init playwrightlatest. Again, I use npm normal, so that'll do it as well. But here we've got it, where we can do npm init. That's one of those commands which you run once in a repo and then good luck trying to remember. For a lot of you, it will start to ask you a bunch of questions on where you want things to go.

I don't like E2E. I like this question. Add a GitHub Actions workflow? Don't mind if I do, right, absolutely. Install the Playwright browsers? That seems like I need it, now I probably have it in my cache. That probably went way faster for me, but that's okay. One thing you notice and I just say this in case you have a need for it, it can go on the internet and do things too, right?

It can go to any URL, you give it. So if you want to automate a browser to do things. And when we see some of the other tooling, you'll see why that could be useful for all sorts of terrible reasons. So some things that I would like to call out, that I think are super interesting for our purposes, and it may be partially intentional on my part is to look at how a Playwright test is structured.

All right, it's got a test, it has a title. They are all async functions cuz we're controlling a browser, let's be clear here. You do get this page object passed in, all right? And there's some other things in there as well. But it's really interesting how you find stuff on the page.

It effectively has the same syntax or API as the testing library stuff that we did earlier, right? So for instance, if you're like, hey, it was really great to see that we talked about some of the nuances of component testing and we discovered some the laughs that we had along the way, I don't have that.

That many component tests, to be totally honest with you. Partially, cuz I didn't like enzyme as much, right? There's lots of reasons. I do think that for me, it is unit tests and Playwright tests predominantly, right? And so I think some other people have a lot of component tests.

I'm kind of scooped in the middle, I've got the unit tests in that spectrum. And I've got these, but that's just my taste and I don't want to enforce my tastes on you, which I've definitely been doing, but it's fine. But generally speaking, I like this as well but the trade off is slower.

And when it breaks you're not gonna get anything log to the console with the diff of the snapshot and why it's broken, right? If you can figure it out, but it's gonna be a little bit different. But the important part that I bring up here is it lives other than some awaits.

And the idea that there are methods here instead of having to use user event or fire event, and you can't actually fire events, because this is truly your driving a browser like a customer would. You have to almost do this stuff, like we're building up to something on purpose.

And you can click as a method this time. So there's little nuances here, but generally speaking, super powerful for kinda spinning up. So, let's go ahead and let's do npx Playwright test. Let's hope that I picked the right repo, I don't embarrass myself once again. It's Chromeum and WebKit and all those things, and then it shows me a report, right?

The report is an HTML file. Let's go run that as well. Cool, and you can see all the different tests, it says, do you have a title? And I can see everything in here as well. And this is really not all that interesting, shows you everything so on and so forth.

What I would like to bring your attention to is, there are ways you can do everything if you don't have VS Code, but I haven't walked around the room, looks like almost, is anyone not using VS Code? All right, cool. There is a plugin, you don't need it, that does that kind of test filtering that we saw before, where I can run a given test.

It also has a hotkey, which is Cmd+; and then the letter L, we'll run the last test again, which I believe also works with Vitest. If you've got that plug in as well, so you can do, if not, I still go and run npm test, or later watching cuz I just muscle memory, but it's typical.

And you're gonna run these tests like this as well. And this one will spin up the browser, and you'll kind of see it do its thing, and it will leave the browser open. And that is somewhat an important point that we're going to deal with. Also, you'll notice that if you have the plugin installed, I mean, you can not leave the browser open as well, that's a thing.

But I really like these, and this will relate back to, even if you're like, no, I like my component tests. There is a reason why you might still do some of your components tests developing in Playwright as well. The big question is, with my screen this zoomed in, can I show two windows at once?

We're gonna find out together. I'll put that one over there, put that one over there. Yeah, that works. We'll close this sidebar, and one of the things you can, I needed the sidebar, you can do this pick locator. And you can see, look at that. People ask me before, how did you know that thing had the role?

I cheated [LAUGH] I cheated hours ago. Honestly, a year ago to the point where that's how I kind of have an intuitive sense about these things.
>> That's from the Playwright extension?
>> Yeah. And it spun up this browser and then it puts it in here.
>> That's awesome.

>> And then, it'll paste it on my clipboard or whatever, right? So that will give me, and I'd have to have the page dot, right? I picked the same one for funny reasons, cuz it was a button on a page. We know that the simple finding of that button means that it is on the page.

If that button was to not exist, so for instance, This one will definitely not exist, and then we were to run the test, it'll fail. So, right, minor, right? Don't embarrass me.
>> I think, yeah. Should it fail like that, with the click?
>> The big question about having used that many frameworks much in a row is, am I slightly mistaken or did it just not run again?

We'll see.
>> Cuz the expect would be true no matter what, you've already clicked on the first link.
>> But not finding it should fail, but also did I actually run them, was I talking, was I really paying attention? I don't really know. You usually know that you're in bad shape, because the wait for and testing library, animations happen, network requests take a certain amount of time, especially cuz we're the real world at this point, right?

It is driving this browser, and things take time, so you can see it's got a test timeout of 30,000 milliseconds for those keeping track at home, that's 30 seconds. And so, you can tell by the spinning that things are gonna go poorly. This sidebar plugin is great when it's great.

If you try to cancel tests midway through, you will end up in a bad state [LAUGH]. It is great when it works, and if you get into a weird state, you need to quit VS Code and open it again. That said, what it does, well, it does so amazing that we deal with its peculiarities.

At certain points, this test fails, cuz it tried to click on a thing that didn't exist. Maybe I'm just mixing up, it might be a different selector as well. But yeah, so what's super powerful here is, you saw how easy it was to get a selector. Don't worry, this gets better.

You saw how easy it is to get a selector, and you know that if you had three, four, five, ten, one test that went through and hit all the critical parts of your code base, right? Can you be relatively certain that you didn't break anything in a very serious way?

Yeah, right? And that's, I think, one of the really kind of powerful parts.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now