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

The "Creating Screenshots" 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 generates screenshots with Playwright. Screenshots can produce failing tests if the visual difference exceeds a threshold. They are helpful when refactoring a large code base because they ensure the UI remains the same.


Transcript from the "Creating Screenshots" Lesson

>> That said, there are a few more things that I would like to bring your attention to. In the name of how do I get as much test coverage as I possibly can as fast as possible. So let's say we have a test. You know what this test is as good as any.

Except for the fact that I hit record. I hit record from the base URL. Let's go, this is a little bit of a simpler test. So we've got that in place. Let's go ahead and. Let's grab-
>> Was there a weirdness with the copy paste in that big text?

There's no spaces between the restaurants, not sure if that's important.
>> Where?
>> Line 6.
>> I probably need a better selector. That's probably the select box which clearly needed a better data ID.
>> Sure.
>> Right so, because there was either no data ID. Or I messed up on the accessibility for that one.

Again, you end up making better choices, this is literally just grabbed an old app. And I thought it was better. Because it is a two-year-old app that I haven't looked at. And I can just get test coverage for it. It's like using a beta version of SvelteKit, which is possibly part of my problem right now.

And, yes, that's probably I need probably either a role. Or like at least a data ID or something along those lines. I'm guaranteeing you if I looked at that code, it would fail the aXe violations on the component test. Because there's probably not a label, right.
>> Going to catch those live coding issues though, as we go.

>> And so yeah, that would probably fail it as well. With the aXe violation, but we can get most of the way there. You know what, let's actually say that we would like. Get by role combo box name is restaurant. I wonder what I clicked there that got me, let's see.

I mean, I say that like I literally could not run this automated test and see. But it's actually not that important. So let's go ahead we'll say this get by role. I like this. And we're not good. Yeah, we'll select an option. I'm sure it will await that.

Actually, I'm gonna do [INAUDIBLE] restaurant, Select. And then what we will do is we will go ahead and just use that. Sweet, and then what happens if I run that test? And I was just showing you, mostly trying to simulate my workflow. Other, also look in the VS Code one, you will get, I didn't go to the page.

This is gonna fail. Don't cancel things because things end up like. This is all the playwrights stuff is great, the VS code plug-in. I'm sure people were like. The fact that it's unreliable is, just remember how magic it is like we all aspire to, What is the-
>> Are you sayinc that stopping tests early is bad for the extension-

>> It has hurt my feelings before and got me in a weird state. Now I didn't do that that's not what got me the weird state earlier. But I have been hurt by it before.
>> Just for the extension.
>> Just for the extension, yeah. Normally you can, yeah, go ahead in the command line.

>> That's what I said.
>> Command C to your heart's content. Let's go ahead and let's run that again. The nice part is like with the thing, it will usually leave my browser in that state. It seems Jack in the Box is picked. Could I get this entire table?

Let's just grab this. Let's grab this element here, right? Cool and did I go paste now? Let's do the pick locator. Or get the entire page. It was the table. The table was our gross giant thing. Const table equals page that I get my text. Yeah, I should put a test ID on that and then I would get something a lot smaller, nicer.

No, we're not doing that right now. This is about not refactoring your code immediately. This is about setting up the test infrastructure so you can refactor. Let's be intellectually honest about what we're doing.
>> Cool, it's value, but never read. What I would like to bring your attention to is when it comes down to then, like.

Getting those sanity checks, like clicking on stuff super great. But, here's an assertion that I can make real fast, that'll make my life a lot easier. So we'll call that table. And then we'll say maybe like to have, what's that one? To have screenshot. And I'm going to spoil where I'm going with this for a second.

I don't know what the other one does. And let's go ahead and let's. I think this taken the most snapshot test fails the first time because there is no snapshot. And now it passess, right and if I look in my file system I got this new folder with snapshots go.

And I have a visual image of the DOM as it was rendered in that moment. Right and so that I can theoretically not only automate a bunch of tests. But I can also take a bunch of screenshots. Also the to match snapshot will write a text file of the text content.

Or whatever of a like if you grab if you say like. If you say h1.txt content or whatever you can actually write that to a file and have a validate that as well. So you can click around and do all these things. You can even just throw in a few like.

Hey this text content should be what I think or should match the screenshot. Obviously you can put in a file name and separate it by what browser and what OS you're using, right. And stuff like that because Windows has different fonts. Safari makes everything shiny.
>> [INAUDIBLE] space though?

>> What's it?
>> It must take up a bunch of space?
>> Yeah. It's their images. They put a little bit of space.
>> Yeah.
>> Right, you got to do stuff.
>> [INAUDIBLE] 100 pixels?
>> That is the test will fail. If it takes another screenshot that has more than 100 pixels difference.

>> And you're like, yeah, well kinda like map what pixels don't match. And you could have a threshold because maybe like, I don't know, like layouts are weird. You know what I mean like stuff can change a little bit. You don't necessarily want your tests to fail because of that.

But you can set a threshold that you want to fail. And like you can very quickly get a whole bunch of test coverage really, really, really fast. Not great test coverage because cool, good luck figuring out why that div moved, right? But at least for a sanity check as you start to embark on that large refactor.

And if you're moving to a different framework or you're trying to just untangle some stuff. Because you don't have to untangle so you can test it. But like In the absence of those tests, you don't know the breaking stuff. You could theoretically automate because otherwise, we all know how the tests were gonna work.

It was gonna be you manually doing this better than that. And the fact that you could theoretically just stop. That you can comment out lines of code, the browser will be left exactly where it was. And then you can open up the developer tools and poke around is pretty powerful.

But wait, there's more

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