🏗 Testing Web Applications with Playwright
Cloudflare Platform Week: Developer Speaker Series
As part of Cloudflare's Platform Week, we're thrilled to feature an array of expert web dev speakers, developers, and educators here on Cloudflare TV.
Testing is hard, testing takes time to learn and to write, and time is money. As developers we want to test. We know we should but we don't have time. So how can we get more developers to do testing? We can create better tools.
Visit the Platform Week Hub for every announcement and CFTV episode — check back all week for more!
And join the community and members of the Cloudflare team at the Cloudflare Developer Discord
Hey, everyone. Thanks for having me here on Cloudflare TV. This is very, very cool.
I'm here to talk to you about testing web applications with Playwright, because I think it's time that you played your tests right.
So a little bit about me. My name is Debbie O'Brien.
You can follow me on Twitter, debs_obrien or my website, debbie.codes.
I'm an international speaker, teacher, YouTuber.
We are all YouTubers these days, an open source contributor.
And I also love sport.
I do have a life.
It's very important to have a life. You'll always find me and you'll see me on Twitter, on my posts, I'm running, cycling, skiing, paddle, I'm a fourth degree black belt in Taekwondo, so be aware.
And yeah, I'm a GitHub star, a Google developer expert, a media developer expert and a Microsoft Most Valuable Professional.
This is one of my favorite photos.
This is actually me coding in the Antarctic waters.
When I went to a conference on a cruise ship in the Antarctica, that was very, very cool.
So yes, remote working is the way to go. Okay, so let's get started.
So testing is hard, right, you know, testing is something that takes a lot of time to learn.
We have a lot of problems right now that a lot of people are not testing their applications.
Why are they not testing? Because testing is hard.
Why is testing hard?
Because they haven't learned it.
Because we're sending junior developers out there into the world and we're not even teaching them testing.
Testing is seen as something that a senior developer learns, something that is done later on.
Testing takes time to build. So many companies and agencies will turn around and say, Let's just cut the testing out.
Let's not do testing, let's build the applications, ship it, and then we'll test later because time is money and they care about money and they don't want to spend the time and invest the time into testing.
So what do we do?
How do we get more developers to write tests?
I mean, we can change the whole education system.
We can force testing upon everyone we can like make sure our developers are learning it and testing it.
But it's hard.
So what do we do?
Maybe we could create better tools.
If we change the tooling, maybe we can improve and help developers write more tests.
So let me tell you a little bit about Playwright.
So Playwright, it's reliable end to end testing for modern web apps.
So basically you're testing something like from start to finish, say for example, it could be a login form where the user comes along and types in their their username on their password, clicks the login button and then goes to a certain screen to log in.
These are things you want to test.
You want to test what the user is doing.
Playwright can run on any browser, so you can test on Chromium, on WebKit, on Firefox and on any platform.
So mobile or the web, with One API tests are run in full isolation, fast execution and powerful tooling.
And I'm going to talk to you a little bit about powerful tuning of Playwright, so stay tuned.
So first of all, let me tell you how you get started, because it's really easy.
And I know we shouldn't say easy, the word easy, but it is so basically to get started with Playwright, to run from your project's root directory.
So whatever project you want to run your tests in, you can do npm init playwright@latest.
So you can even just do this right now while you're listening to me or you can create in a new project.
So you might have a project you want to test on.
You just want to like keep your test separate.
That's also totally cool.
Or just like play around so you can do npm init playwright@latest new-project.
new-project is a terrible name, so it makes you give it a better name than that.
Once you've got it started, what can you do? Well, another way to get started, let me show you actually is using the VSCode extension.
So if you don't want to get started the way I showed you, you can literally just open your VSCode editor and install the Playwright test for VS Code extension.
Make sure you look for the verified symbol from Microsoft so you're installing the right one.
There's a couple of them there.
So install that.
That's pretty simple, right?
You can get that done.
And then all you've got to do is use the command bar to install Playwright.
Now when you're installing it, it's going to ask you a couple of question, right?
It's going to say, Do you want to select all these browsers to install or do you want to just start with Chromium and you can select them all and then you can later on add Firefox and Webkit if you want to.
You can have them all at the start, whatever.
It's up to you and you can also add GitHub actions as well, which adds a cool GitHub action recipe.
So again, that's an easy way to get started. So we've now all got started.
What happens next? So after you install, what you actually get is a package.json, right?
This is going to give you everything that you need to get everything working and the Playwright config file, which is obviously what you're going to use to configure it anything.
So if you want to change something, add Firefox instead of just having Chromium, for example.
That's where you do that plus every other thing that you can config and it's going to give you a test folder with example test file.
So there's a really great demo project in there to do up with loads of test written and you can follow along and you can like really play around with it and see how that works.
I'm not going to talk to you about that today, though. I'm going to talk to you about how you can actually get started in writing your own tests, because normally when you're given a demo, it's kind of like, write this down, really cool, but what do I do?
How do I get started?
Where do I think about how do how do I even just get started?
So that's what I'm going to show you.
Now again, testing is hard, our developers are not learning how to do stuff, so how do we get new developers on board to test easily?
So let me introduce you to a really cool tool called Cogen.
So Cogen will generate tests by recording your actions.
Now this is really cool.
So basically you can just click around and Cogen is going to create the code for you.
Very cool. Let me show you.
So first of all, what you'd have to do is go to npx playwright codegen to get it running.
Once you do that, what you're going to get is two windows.
So one over here, you'll see that I'm going to type in what I want to test.
So I'm going to type in the URL to my application, which is my ecommerce demo site.
And you'll see on the right there, I've just started creating code for me, right?
It's already just written test. It said awake, go to page and it's given that for me so I can scroll down and say, right, this is my app, what do I want to do here?
So I'm going to buy some shoes.
So I'm going to click on the women text and you can see the selector there.
It said Await expect page to have URL after it's selected, the text equals women.
Okay, that's cool. So let's put that into the code for me.
So my code is being written.
What else can I do here?
So I think I want to put some shoes into the shopping cart, so I'll do that.
I'll scroll down and as I'm like hovering over, you can see like it's giving me the selectors that are possibly going to be able to be used to write the tests.
And I basically want to select this product.
So again, I'm clicking that locator in there and I'm expecting the page to have the URL.
Now go a new page with my shoes. So let's, let's add two shoes, two pairs of shoes in there.
So I've got page.locator text is plus, let's add a size, let's add 39.
So you can see the locator was the select and the option was 39.
And then the color I've got a dot to test idea of blue and then I click that one and then I click the add to cart.
So now I'm adding my product to the cart and then up at the top you'll see my cart now has two.
So that has two products in there because I put two pairs of shoes in there and I'm now on the product details page of my shopping cart and I can also remove it, right?
Test that works, remove my shoes and now I can check that it says no products are in the cart.
So this is my user experience and this is what the user is going to do.
So now I've got this test, I can stop the record and I can literally like see all this code that was written for me.
Now I'm a new developer who doesn't know how to test and bag.
I've got my tests written.
How cool is that?
So literally, like just right now, just go and do that on your site and then like send it to your boss and then ask for pay rise.
So yeah, you can basically just copy that and they'll use that code.
Now, of course, like some of the selectors, you'll see they're maybe not perfect on line 13 there's a dev with the child five and that's maybe not the best selector, but it's a very good starting point.
Then you can go through them and you can improve those selectors and improve that code even more so.
Yeah, great way to get started now.
Also very cool, it works in multiple languages so you can actually if you're a Java developer, Python developer, dot net developer, you can still use Playwright and that's kind of cool.
I'm not a Java developer and bang, all of a sudden I've got all my test written in Java.
Very cool. Or you know, doesn't that I don't know how to do dot net but there's dot net stuff, done, easy.
So now we've got that done.
We need to start running our tests.
How do we run our tests?
Well, we want to — we can run all our tests or we can run a set of tests or we can run a single test.
We can also run, well, all tests are run in parallel.
So when you're running a load of tests, they're all run in parallel.
You don't have to do anything that just out of the box.
So that makes them super fast.
The easiest way for me to run the test is actually just using the VSCode extensions of the Green Triangle.
I'll show you that in a minute.
But you can also like run it in the terminal.
So if you want to run the tests headless, you can do npx playwright test, right?
What that's going to do is just going to run those tests in the terminal like just being done, tests done.
You're not really going to know what happened.
But it's cool because your test passed and that's kind of all I care about.
You can also run headed which is np playwright test -- headed.
Now this is kind of scary at first because it like opens up a browser window and it goes do do do do do and like goes through the test because it's so fast, like just flashes before your eyes.
I'm like, that's a test done because that's how fast it is, which is really cool, doesn't help with debugging, but I'm going to show you later how to do that.
But yeah, if you want to see what's going on, use the headed option there. So again, I said my favorite way is using the Green Triangle, so let me show you that.
So I'm going to paste in my code here, which is the code we just you just saw me create from codegen and I paste it in and then I'm going to save that file.
Once I save that file, I would expect I've got then the Green Triangle. So on line 3, there you can see that green triangle.
I just have to press that and it's going to run the test.
So that's a kind of quick way of running my test without like opening anything and doing anything.
And did you see that? Did you see it just like you missed it?
So first, yeah, it's just like run through that test so fast, it's like 2.5 seconds, right?
So buying my test is green.
All right. I can go home now. Yay!
Took over. No. So what happens when you break tests? Because we do break tests, don't we?
We do our developers test break.
So the code also gives you these great error messaging, which is really cool.
So let me show you.
I'm going to like break my test.
I'm going to like change the text of women to men, and then it's going to go to that URL of women and it's going to say that's the wrong one, right?
It's going to break on line 9.
So let's run the test again and you'll see it's going through it and then whoa, it's stopped there in line eight.
Whoa, hang on a second.
I thought it was going to break on line 9, but look at the error messaging in here.
Like, I can literally, like, look at this and say, okay, what is going on? It's basically telling me that strict code violation text equals men resolved to two elements.
Okay. And it's telling me, like, you know, the text equals men.
I have like two options here.
I've got men, aka Playwright, Text equals men.
That's the kind of option I can use.
And why is it?
Why is there two men?
Because the word men is in the word women as well.
And it's like that's strict that it's basically saying, hang on, I found two cases where men could be a possibility.
So it's like, okay, I'm getting you so I can kind of see what's going on here.
I can see, right?
How can I fix this?
It's given me an option here.
Do I want the first instance of men or do I want the text equals women?
Well, because I want to break my test, I'm going to take this option just so I can show you that on line 9 it's going to break.
So this is the taking the first instance of men on the back I'm going to run that test.
And now on line 9, it's going to find the wrong URL, hopefully.
Let's take a look and here we go.
And bang — line 9.
It's like, hang on a minute, I can't find that page. This is like, you know, this is the wrong page.
I'm getting a different page than the one you're expected.
So I expect it to go to the women page.
And the one I actually received was the men page because it clicked on that men, which that makes sense.
That's kind of like a test that kind of makes sense now.
So that was kind of cool, right?
So let me tell you a little bit about no queries because we kind of see in a couple of things there with strict modes and locaters.
So let me explain what they are.
And our locator is a way to find an element on the page at any moment with built in odor weighting and retry ability.
That means you don't have to do any timeouts to get things to like wait.
And it's just going to retry until like, okay, I've found what I'm looking for.
So it's kind of like a ping on a Google map kind of thing.
That's your locator on the website.
So locator is a kind of created with the page locator.
Then you put your selector in there, your options on the method.
So it's strict by default, so everything's going to be strict.
So we're starting off with a weight, must be weighted.
So a weight then we're using expect and we do expect page locator.
And then here I'm doing like header and the knob should be inside the header and I'm expecting that to have the text.
And as you can see here, I've just to be different.
I'll put an array in here.
So I'm expecting it to have men, women and children.
I want to make sure that those three are in that navigation. So basically, yeah, it's going to wait until it has those three elements with the given texts and then great.
So there's a lot of things that you can do with locators.
There's a locator to click the locator to count located to drag to.
There is inner HTML, there is hidden, there is visible.
Well, a press first takes content.
There's a lot.
So I encourage you to study that in your own time. Let me show you something that I've been doing with the ecommerce demo.
So, we talked about locators before and I showed you like how the men and women was a problem because it has the same text, right?
We can't have anything like restrict mode, we can't have anything the same.
But what happens when I have like the buttons and the all at the same text and the page see product details.
So how am I going to make sure that I want to click the first one or the second one, whichever one?
So what do I do in this case?
So this is when like we could just see us as selectors, right?
So we could turn around and say await page dot locator div, we're going to get the Nth child one card, shoes, card, shoes, card, footer up button and click.
That works, right?
And that's kind of what like the codegen is giving me.
Now, it's not the best solution, because what if we start playing around with this?
Because I might like just turn all that into tailwind success tomorrow, our next minute, all those CSS classes are going to be gone out the window.
So that can be an issue.
So be very, very careful about using CSS selectors, but they obviously do work great depending on your use case.
So just be aware of that.
Another thing we can use is locators plus has text.
So again these are case insensitive substring match and accepts both strings and regexes.
Now I'm using CSS selector here just to show you, even though I kind of told you don't always use CSS, but maybe in this case the shoes card is a better example of this one, is not going to change, whereas the day of obviously kind of wasn't a great example.
So here I'm doing a await page.locator shoes card and I want that to have has a text Guchi.
So I'm going to look into that class of shoes card and I'm going to make sure the text Guchi exists.
And then I'm going to look for a locator with a class of button and I'm going to click that.
So that's kind of one way of doing it. Now, what if you have like your shopping cart page where you put all these into your cart and you want to remove them.
So I want to select the remove from cart button from one product.
So this is something else we can do.
We can use locators plus has with the two like dots there the colons.
So the house option makes sure it contains another locator inside it.
So here I've got my row of products and I'm going to say await page dot locator dot row.
So I know this, this is my class don't row and this time I'm saying has, I want to make sure it has a page the locator image with an alt of Guchi.
Now I could use text equals Guchi, but I'm just showing you a different way of using the locators.
So image and I want to make sure alt is Guchi.
I'm also checking and making sure my alt tag exists here.
So that's kind of cool, kind of killing two birds with one stone.
And then I'm going to check that the locator and again, instead of doing text equals X, I'm doing area label equals remove from cart.
So you can see here has page dot locator image of alt equals Guchi that's going to select that area only it's now going to focus only in that area.
And it's going to say, I want to find something that says area labeled remove from cart and it's going to find that X button and then it's going to click it and it's going to click the right one and bang, it's going to remove the Guchi shoes.
Oh, poor Guchi. So a frame locator is something else that we can test very easily is eye frames so we can, Playwright will basically order wait your iframes to appear on the page and then it will test it.
So you can see here I have an iframe, a video coming from YouTube there, okay, it's video of me talking.
But imagine it was a video of Guchi shoes on your e-commerce site, for example.
You want to make sure that that video is there, that the video is playing, and that it's actually coming from YouTube and working as it should.
So how do you go about doing that?
So to do that you would use frame locators.
So it's going to automate the iframe to appear.
So if I want to test that play button, for example, I can basically say constant pause button, I'm going to test that it pauses, using the page dot frame locator and I'm looking for an iframe.
I know there's only one iframe on this page, there might be more than one, so you can you can play with the selector if you have more than one iframe there and I'm going to look inside that frame.
So it's now only inside that iframe and it's going to look for a locator with an area label.
Of course, that's how YouTube has done their area labels with the pause button.
So that's where I got that code from. So I'm going to check that that is actually there and that it's clickable.
So await, pauseButton.click bang.
That's going to click the pause button and then I can do the same for the play button.
Obviously the play and pause should work. If one of them works, the other should work.
But you could always test them both.
So that was easy.
Now, what about running debug mode?
Because, you know, we always have problems we need to fix.
It all looks very easy, but sometimes your tests just don't work the way you want them to.
So when that happens, we can run debug mode so we can put in terminal npx playwright test -- debug.
That's one way of doing it.
And another way is basically using the VSCode extension.
So right in here on line 8, I'm going to click that and let's put a little red circle there.
That's my debug. And now I can like right click and then choose the debug test.
This is now going to run my test in debug mode and as soon as it gets that breakpoint, it's going to say, right, I'm going to stop here and I'm going to see what's going on.
So it's going to stop there.
And as you can see, it's selected, the men that are text equals men, but it's also highlighted the women there.
Right, because we have that problem where men text is men and also in women.
So we've got like a duplicate issue here.
Again, I can play around with this in debug so I can say text equals hello for example.
And what happens. Well, obviously I don't have any hello on my page so it's kind of saying nothing there.
I can do text equals children and I can check that out and it's now giving me the selector of text equals children.
So this is great fun way to kind of like debug and see what selectors are working and what selectors are not.
Now we can also have a look at reports.
You can basically have like generate a whole report of your tests.
You can do that with npx playwright show-report.
Now, once you do this, what you get is this kind of cool report.
So let me just explain it a little bit.
This is my cart.spec.ts file and I'm like, I have a Chromium label there because I'm just running my tests on Chromium.
But you would have like WebKit and Firefox if you were running on those as well.
And then basically you've just like got each step and you can go to each step and you can click and open it and see exactly what's going on in each step at all times.
So this is kind of really cool and then it gets even better than this. Wait for it, wait for it, wait for it.
We need to trace files, right?
So to get trace files, just go to your config file.
That was when you started and got your tests up and running.
We had a config file just go into there and basically in the use put trace equals on you can do it just on like tests that are failing.
But I want to trace all the time because I just want to see what's going on.
So trace on it's going to give me the trace file all the time.
What does that do?
Well, remember we had our show report, so here we go to show.
And then as we kind of go down, we rerun that report. We're going to get a traces, which is basically a zip file and there's a little image there and you go, okay, what are you talking about?
Let me show you.
It's really cool. So the trace file, basically you click on it and what it's going to do is it's going to give you this, right?
You're going to go, what's going on here?
This looks like a browser kind of dev tool kind of thing going on, right?
So basically that's kind of what it is at the very top there.
You can basically scroll along and you can see like the locator click text equals women.
You can scroll along at each stage and see the loading of the page and what stage it's in.
Over on the left there it's got the actions and the metadata.
In the middle you've got the action, the before, what happened and after when you clicked it.
And then on the right you've got like the code, the console and network and the source.
Again, let me show you, because it makes more sense when you watch it.
So this is it in action. This is every single step of my test and I can walk through each one.
You can see that it's changing there in the middle.
You can see each step that we're going through.
So we can really understand what we did in our tests and what's going on at all times.
Now we can hover over across here, scroll along and basically like see, you know, there's the load state, this one there uploaded this is when I click the text equals women.
This is when I navigated to the URL.
This is and you can see they're all color coded right, to show different ones, like the select there is red, the other one is green for a click.
So you can see all those actions that are happening and you can scroll and kind of see what's happening.
Again, I'm going to click here and just see the action.
So the action there is on that red dot of Texas women before and after the pages of women's shoes, the selector text equals women.
Strict is true and the whole log is written there for as well.
So you can kind of see what happened there and what was clicked.
Again, the console I have no console errors.
And the network, you can see all the photos, all the images that kind of were coming down.
And my source code for all those tests, you can see every single line of code that was written for that test to happen.
So that's one way of basically going through your tests one by one.
Now, you can see there, I've got on line 3 ,test and I've got like just the name test.
So you can obviously change that and give a better naming to your test and that will really help make things easier when you're kind of debugging, etc..
Now, the really cool thing about this is what's in the middle is actually a dumb snapshot.
So it kind of looks like an image and it's kind of like you're looking at this and saying, Right, that's just an image, but it's not an image.
It's actually a DOM snapshot.
What does that mean?
So it means you can interact with the DOM, you can inspect it and you can play around with it, which is very, very cool indeed.
Here's a video of it.
So I'm going to click on text equals women.
I've got my DOM snapshot, right?
So I just make a little bit bigger.
So I've got more space and I can scroll along.
So this is my website.
It's not an image, it's my actual DOM snapshot, which means it's a web, which means I can click it and now I've got the children's section right, I can click the mode and now I'm on like light mode, dark mode, and I can even inspect it and actually just open the developer tools.
And that makes it really cool because I can start really kind of playing around there with the selectors and checking that out and seeing what's going on and seeing if there are other selectors that I want to use, etc.
So this is a really, really cool tool for debugging, for showcasing it to people, for really understanding your tests, for absolutely anything and everything.
It's a really, really great tool.
Now this looks like, you know, that your your trace files are basically like up there in the cloud, right?
And everyone can see them.
But that is not the case at all.
It's actually running on your computer only.
It's basically like a way that gets, you know, just hosted on your local host.
It's a zip file that you can say you could share it with someone else if you wanted to.
But it's not up in the cloud. Nobody has your code.
It's completely safe and just running on your computer.
So that's really cool.
So basically, Playwright testing.
We basically had a look at what the VS Code extension does.
So I highly encourage you if you're using the VS Code to use that extension and get started with it.
If you're not using VS Code, then just use the other ways in the terminal of getting that up and running, codegen, again.
A very, very cool tool which will auto generate the test for you.
Again, it's auto generating things.
It doesn't mean the tests are amazing.
So do obviously go over the code and improve things and make it better, but it is a great way to get started.
And if you have some junior developers in your team, some people who are new to testing, never tested before, this is going to give them a lot of confidence and it's going to help them really, really get started.
And it's going to like take away the whole workload of just thinking about how to write those tests.
Block the if, block, and they expect and what is the next word, right?
Get them started like this.
And they're going to start like really writing amazing tests.
We also looked at how to run in debug mode right there in vs code, just clicking that button, adding that breakpoint, really simple.
We talk about locators and frame locators.
You can choose from CSS selectors to area labels on iframes and you can like really dive deep.
There's a lot of locators there, a click and it's hidden, it's visible, etc.
We took a look at how to show reports, right?
So you can actually see a whole report of all your tests and be able to go through all of those.
And also then showing the trace files. You can really like open that up, go to all those trace files and really understand what's going on and play around with that snapshot as well.
So, Playwright testing auto wait built in for all actions.
So there's no need to set timeout calls or doing anything like that.
Tests are running in parallel, which means it's super fast and remember it runs on multiple browsers and devices, so it's going to run on web, it's going to run on chromium, it's going to run Firefox is going to run your on your iPhone or whatever device you're using, which is very, very cool.
And intercepting requests that follows all redirects.
It bypasses course because we all hate cores doughy.
And it manages cookies for you.
So yeah. Very, very, very cool.
And I highly encourage you to check it out.
Remember, Playwright is open source.
It's free to use.
It's absolutely no cost at all. So just go ahead and try it out and give it a go.
Seriously, like, are you ready to Playwright?
I mean, I hope you are. Thank you very much.
If you want to find out more information, there's a docs site there.
You can follow the docs, read the docs, follow the YouTube channel for the videos that they put out and they have a Twitter channel and there's a Slack channel where you can jump in there and ask your questions and dive into the community and maybe even help out yourself.
And again, thank you very much.
My name is Debbie O'Brien.
You can follow me on debs_obrien on Twitter and my website, debbie.codes.
Thank you very much.
We're Cloudflare. We're building one of the world's largest global cloud networks to help make the Internet more secure, faster and more reliable.
Meet our customer, Wongnai, an online food and lifestyle platform with over 13 million active users in Thailand.
Wongnai is a lifestyle platform, so we do food reviews, cooking recipes, travel reviews, and we do food delivery with Lineman and we do POS software that we launched last year.
Wongnai uses the Cloudflare Content Delivery Network to boost the performance and reliability of its website and mobile app.
The company understands that speed and availability are important drivers of its good reputation and ongoing growth.
Three years ago we were expanding into newer services like a chat bot.
We are generating images dynamically for the people who are hearing the chat bot.
Now, when we generate image dynamically, we need to cache it somewhere so it doesn't overload our server.
We turned to a local CDN provider that can give us caching service in Thailand for a very cheap price, but after using the service for about a year, I found out that the service is not so reliable going to do Cloudflare and for the one year that we used Cloudflare, I would say that they achieved the reliability goals that we expecting for.
With Cloudflare, we can cache everything locally and the site would be much faster.
Wongnai also uses Cloudflare to boost their platform security.
Cloudflare has blocked several significant DDoS attacks against the platform and allows Wongnai to easily extend protection across multiple sites and applications.
We also use Web application firewall for some of our sites that allow us to run open source CMS like WordPress and Drupal in a secure fashion.
If you want to make your website available everywhere in the world and you want it to load very fast and you want it to be secure, you can use Cloudflare.
With customers like Wongnai, and over 25 million other Internet properties that trust Cloudflare with their performance and security, we're making the Internet fast, secure and reliable for everyone.
Helping Build a Better Internet.