In this video, you are going to learn everything
that you need to know about testing your React applications using Playwright. Playwright is an
end-to-end testing tool that literally allows you to test your applications exactly as a real user
would. And it does that by spinning up a browser, running your application, and going and clicking
on things, typing on inputs, and making sure that your application behaves in its entirety, that
means frontend, backend, and database included, exactly as you expect, and that there's no
unwanted surprises. So get ready, get excited, because you're going to learn a lot in this video.
And by the way, if you want to learn how to build a big and complex application with React as a
total beginner with no prior experience needed, check out Project React in the description.
Trust me, you will not regret it. Let's get into it. All right, so over here, I have a very
simple application that's running locally. And now we're going to want to test this application
using Playwright. This is obviously a very simple application. We have the homepage over here. We
have this h1 tag that says homepage. We have this form over here, which is a link. If I hover it,
my cursor turns into a pointer. And I can click this. And it's going to redirect me to the actual
form URL over here, slash form, where we get to see the form. And we have an input field over here
where I can type something, for example, test. And I can press Add. And we're going to add that item
directly in here. And the input is going to be cleared. Again, this is a very simple application.
And we're not going to look at Playwright and how to write tests integration tests for this
application. So to do that, we're going to go here to the actual documentation of Playwright that is
going to be at playwright.dev. And in this video, what I'm going to do is I'm going to show you
how we could test this very simple application. But more importantly, I'm also going to walk
you through my thought process of what to test because unfortunately, a lot of tutorials don't
actually show this to you, they show you how to use the actual tool in this case, Playwright, they
show you how to write the test and all of that. But they never teach you the core principles of
testing and why you should test something in the first place. And more specifically what to test
versus what not to test. So as you can see here, Playwright enables reliable end to end testing
for modern web applications. If you don't know what end to end testing is, as opposed to unit
testing, end to end testing means that you're taking the entire application and you're actually
running it with the whole front end with the whole back end and a database. And you're testing
it as a real user would. So you're running the entire application, you're going and clicking
on things, typing on inputs, and seeing how the application behaves as opposed to a unit test,
where you're testing a component or something in isolation. This you're testing everything
the entire application as a whole. So let's get started. And let's come here and click on the
Get Started button. This is going to take us to the installation page of Playwright. And we're
going to follow these instructions over here, which honestly are pretty simple. We're going to
start by installing Playwright. And we're going to do it by installing it in an existing application,
which probably is also going to be your case. In my case, I'm using PNPM. So I'm going to come here
and take this command PNPM create Playwright. And I'm going to come here to my VS code. This is the
actual code that's running the application. And I'm going to run it here inside of the terminal.
This is now going to ask me where I want to put my end to end test, I want to leave this in
the default test folder, it's going to ask me if I want to set up GitHub actions workflow,
I want because this is a simple application, we don't have anything on GitHub, then we're
going to want to install the Playwright browsers, we're going to leave this to default Playwright
essentially runs this test on multiple browsers to make sure that your application runs the same on
different browsers, which is a really cool thing. And after that, we run that command, we have this
nice little lock here, telling us that Playwright is successfully initialized in our project. And as
we can see, if we open up here, the Explorer page on the right, we have two new folders, we have
the test folder over here. And we have the test examples folders. Now the test folder, if I open
up example dot spec.ts, and actually close this terminal, this is just a simple example test file
that Playwright automatically puts to get yourself started. This is cool, we're going to be working
within this file to actually add this specific test of our own application. But then we also have
test examples. And this has a different file over here that is really, really useful. As you can
see, this file is very big, it's much bigger than the first file. And this actually has all of
the tests for a demo application that Playwright built and hosted themselves, you can find it here,
HTTPS demo dot Playwright, let me just come here and open this in the browser. If we open a new tab
over here, we have this application. And this is a simple to do application created by Playwright
themselves. So we can add here a new to do we can do test, for example, press Enter, it's going
to add it, we can complete it, we can also delete them. And we have a fully working application. And
in this file, we have all of the tests for that application to make sure that it works correctly.
And this is really useful, because if you're just starting out with Playwright, and you don't really
know how to actually use it, you can use this file and you can refer to it and see how they actually
recommend that you do all of these tests, right, you have a bunch of code over here for testing
different things, that most likely is going to cover some tests that you're trying to do for
your own application. So this is a really, really useful file. And I would highly recommend that
you spend some time looking through this because there's a ton of things to learn over here that
you can apply directly to your own tests. Now, in our case, we're not going to use it, we're
just going to be working in the simple file over here. And we're going to create our own tests
directly. So what I'm going to do actually is I'm just going to take all of this and delete
this because we want to start fresh. And I'm still going to leave these imports over here
because we are going to use them. So now first, let's think about our application and what we
actually want to test in our application. So here, let me just run the application again, pnpm dev,
just to have it running. And let's go back now to the actual homepage. And let's think what do we
want to test because our application is really simple, we don't need to have any fancy tests.
So when we first start and load the application, this is the screen that we're seeing this is the
home screen. Now this home screen on only has a few elements. So there's not really that much to
test. But still, we should test that what we're seeing on the screen is exactly what we expect.
For example, we should test that we have a heading on this page that says homepage, right, because
we're putting this here, we want to make sure that it actually is there, and that it has the correct
text. We also have this link over here that says form, we want to test that first of all, the link
is there. And that when we click the link, we are successfully redirected to slash form. And here
I have an error, why do I have an error, there we go, it's fixed, that was successfully redirected
to the actual form. That's all that we want to test for this specific page. And also maybe
that the title over here is causal solutions, just for good measure that the title is also what
we expect. Then we also have the form page, which has a little bit more functionality. And here as
well, we want to write our own test suites to test the specific page, we're going to first test the
same thing that the form is actually there. And also that the input and the add button is there,
and that I can type something on the input. And that when I type on the input, that whatever
I typed actually ends up over here in a list, and that the input is then cleared, right,
we're testing the actual functionality of our actual application. And note here that this
doesn't depend really on any individual piece, it doesn't depend on just the front end, on just
the back end, or just the database. But rather, it depends on all of the pieces working together.
Because let's say that I did have a whole back end that would actually save everything that I type
in here, we will also be testing that we will be testing that whatever we type in here, when we add
it, it goes to the back end, it gives us a correct response. And we see it here on the screen.
This is what we call an integration test. Now, of course, in this simple example, we actually
don't have a back end, everything is handled on the front end. But you can imagine that if we
had a back end, we would be indirectly testing that through this integration test. Because the
only way that this item would show up here is if the back end is also working, if the back end
is down, and it doesn't work, or if there's an error in the back end, this test item over here
would not show up. So doing these tests actually test everything from front end to back end and the
whole integration test. And that's generally how you want to approach thinking about testing and
what to test, you take any screen that you have, and you look at what the user can do what any
user can do in your application, what they expect what they can see on the screen. And you just test
those cases those paths and make sure that they're correct. And also, if they're not correct, there's
an error, you make sure that the application your application response in a way that you expect
whenever there's any given error. So in our case, that's the form, the functionality of the
form and what we see here. And that's it, we don't need to test anything else. And in the
homepage, we have no interactivity, we just have a bunch of elements. So we just need to test that
the elements are actually there. So let's go back to our VS code and actually start writing some
tests. So first of all, I'm going to do all of this work in this one example dot spec.ts file,
just to keep things simple. In a real application, you might want to split this up into multiple
files, each related to different types of tests, that's totally recommended. But we're going to do
this in one file just to keep things very simple. And the second thing is, we're going to have two
different groups of tests, because we have two different pages, we have the homepage, and we have
the form page. And it's generally a better idea to group those things together, because related tests
usually have some common functionality that should go in the same group. So let's go back to VS code
and actually start writing some tests. Now the way that we're going to do this is first of all,
I'm going to write everything in this one file example dot spec.ts, just to keep things simple
for the video. But ideally, in a real project, you might want to have separate files, each for a
different group of related tests. The second thing is, even though I'm putting all of this in one
file, I will separate my tests into two groups, I'm going to have one group for the homepage
and one group for the form page just to keep things a little bit more organized, so that I
put all of the tests related to the homepage in one block and all of the tests related to the
form page in another block. Now in playwright, you can actually do that you can create groups and
you do that by using a describe block. So let's come here and let's test dot describe. And here
we can actually give it a name. So for example, we can do home page like this, this is going to be
all of the tests that are related to the homepage, we're going to put them inside of this describe
block, then we give this a function over here, an arrow function. And inside of here, we're going
to put all of our tests that are related to the homepage. The only thing that this describe block
actually does is when you have an actual UI, and when you see the actual tests being run, they're
going to be grouped under this category to make it easier for yourself to organize, I always like to
do this. And again, group related tests together in a describe block, because it just makes more
sense. And then in here, we can actually write our tests. So the first test that we want to do
is if I go back here to the actual application is we want to first open up this page over here.
So localhost 3000, because we do have to navigate manually to it. And then we're going to check that
theSo we're going to start by writing a test. So we can do tests like this, give it a parenthesis,
then we need to give it a title. And we're going to do should have correct metadata and elements.
You always want to give this a descriptive test, a descriptive title to actually represent what the
test is actually doing. So should have the correct metadata and elements, this is very clear as to
what this test does. Then as the second argument, we're going to give this an asynchronous function.
So we're going to do async like this. And this is going to have one argument, and there's going to
be an object. And from that object, we're actually going to get the page property like so, because
we're going to be using this page inside of our test. So in this block over here, we created a
test, we gave it a title, should have correct metadata and elements. Then as the second function
is the actual function that we're going to use to test. And this page over here, we're going
to actually use to access different things on that specific page, like access the title, access
any elements and check that they're exactly what we expect. Now to check the title, this is what
we're going to do. And by the way, to really see how to do any of these things, remember that you
have this demo dash to do is app spec over here, you can actually look at this. And you can
find how they get the actual title of a screen, how they get any single element, or you can look
at the actual documentation, I'm only showing you here the simple version of doing things. But if
you want to go a bit deeper and learn a little bit more, you have all of the resources available
to be able to do that. So we're going to write a weight and then expect. So we are going to be
expecting something and this is coming directly from playwright at test, this is this import over
here. And then we're going to do page. So we're going to expect that the page dot and then here's
a helper function to have title. And we're going to give it here the title that we expect, which
is going to be caused in solutions like this. So now we have an actual test and we have some code
inside of it that is going to wait and then it's going to expect the page to have a title of cause
and solutions. This is a very simple test. So as long as we actually open up this page over here,
and that we have a title cause and solutions, this test is going to work. But before we can actually
test that there's one more thing that we have to do beforehand that I left out on purpose just to
make it really obvious how important this is. You cannot actually expect the page to have anything
before even visiting the page in the first place, right? In this test, there's nothing that we're
telling this test to actually go to any specific page, we're just getting the page over here.
And we're expecting it to have a specific title, but what page it doesn't know what URL to open.
In this case, we actually have to give it right before we test something, we have to navigate
to that specific page. And we do that by doing a weight and then page dot go to and this is
a function and here we give it a URL. So for example, HTTP, slash slash local host, and then
3000, like so, which is the actual endpoint that our application is running in, you have to give
this to each test, because each test first of all runs in isolation. And each test needs to be able
to know what page to actually go to. So first, we go to that specific page that is going to
wait until the page is actually loaded. And then it's going to proceed to this line over here,
which is going to check the title of the page and make sure that the title is exactly causing
solutions, which is what we expect. And with that, we have everything that we need to actually run
this test and see if it passes. So the way that you run tests in playwright is you open up the
terminal over here, I'm going to create here a new terminal, because we have to have our application
running, you can configure this to automatically run the application, it's in the documentation, in
our case, we're just going to keep things simple, we're just going to write NPX playwright test. And
then I'm just going to put this command over here, this is going to run three tests using three
different workers, because it runs the test on different browsers. That's why we have different
tests. And all of these tests are run in parallel. So they're all running at the same time.
But as you can see here, we run three tests, and three tests actually have passed. And we can
even have a report over here, if we wanted to, we can just do this run this command, this is
going to actually show us here a report, which we can see. And we can see that we have all of these
tests over here actually running, let me just copy this and then close it and go to Chrome, because
I like to film everything in Chrome. There we go. This is the actual report. So homepage should have
correct metadata and elements. It ran on Chromium, it passed on Firefox, it passed on WebKit,
it passed all of these different tests pass, and we're making sure that our application at
least has the correct title over here, which it does. This passes. Great. Something else that
we could do is we can run a different command, we can run the test command over here with dash
dash, and then UI, this is actually going to spin up a real browser. And it's going to be over
here, let's open up this browser over here, let me just make it the correct size for you.
Let me maybe zoom in a little bit. And here we actually have a UI to actually run our tests.
And there's this green button over here, which we can press. And that is going to run all of our
tests and all of our files. And you see here, we have the homepage. This is by the way, the
describe block this homepage over here, that's why we're selecting it. That's why it's a different
group because of the describe block. And inside of here, we have should have correct metadata and
elements. And we have the actual test over here, page go to and then expect title to have and it
did and it passed. And we are good to go. Our test actually passed. This is a different way to
actually run your test. If you want to visually see how you're actually test are being run. Great.
So now with this, we can actually continue and fill up the rest of the missing pieces of our
test. Because remember, we don't only want to test that this has a correct title, we also want
to test that over here, we have the actual heading that says homepage, and that we have a form that
is a link that we can actually click to and go to the form page. So let's write those tests. So over
here, we're going to test first that we have a heading that is a type heading and has homepage in
it. So we're going to do a weight and then expect page dot get by role. And this is going to get an
element by its role, which we can actually give it a role heading like this. And we can actually
give it some properties over here, for example, the name, and we're going to give this here
home page, like so. So what this is going to do is it's going to await and then it's going
to expect and then page dot get by role, this is going to get any element within the page that has
a role of heading that also has name homepage, which is actually going to be the text inside
of that heading. If we have this, then we can actually validate that we actually do have this
over here. And then it also has the correct text. Because if this did not have homepage, we will
not get this element over here, right. So the only thing that we need to do after that is we need to
call to be visible, because we need to check that this element is actually visible on the screen.
So this test is only going to pass if we have a heading visible on the screen that is of type
heading. And that also has homepage as the text, right? In any other case, it's not going to pass.
But if it has this, it is going to pass. So let's come back here to our actual UI. And let's press
play again, and see if our test still passes after these changes. And it does, you can see here,
expect to be visible. And it's even highlighting the homepage over here, it's getting the actual
heading element, and it's checking that it has the correct name inside of it. And just to be
sure that our tests are actually need working, I like to do this sometime just to really
make sure because sometimes you never know, let's come here and let's actually add an extra E
to make this an invalid name. And now let's see if our test should fail. Because right now, we don't
have a heading that has homepage with two E's. So this test should actually fail. So if you play
this test over here, we're going to see that it takes a little longer, because when it fails, it
actually retries the test. And in a short while, it is going to fail. And it's going to see here
that expect to be visible has failed because we have no actual heading with homepage and to eat.
So now we've confirmed that our test is actually behaving as we expect, and that we can rely on
it to actually fail when it should. Great. So now with this, we can come back, we can fix
this over here. And let's remove the extra E. And let's just test that our link is also
visible. Because remember, we do have a link over here. And we also want to check that this
is visible and that it has the correct text. So we're going to do the exact same thing, we're
going to do await, expect, and then page dot get by by role. And we're going to give it here link
this time. And we're also going to give it name, and it's going to be form like some and we're
going to await and expect to be visible. And we're going to wait for this and expect it to be
visible. Let's come back here to our test. Let's rerun this and we should see all green passing
test. There we go. Our link is also visible. There we go, we have successfully completed our
first actual test testing that we should have the correct metadata and elements on that specific
screen. Great. Now the next thing that we want to test is that when we click on this link over here
in this form link, we are redirected to the form page. Because while it's cool that we did test
that this link is over here and that it says form, we did not actually test that when we click this
form, it brings us to the expected page. And this is also important to test because the user is
going to be able to click on this. And if they're not redirected to the form, then you have a bug
in your application. And having a test for that is going to prevent that bug. So we're going to come
here and for that we're actually going to make a new test because now this is a different test,
we're no longer testing that we have the correct metadata and elements, we're actually testing that
when we click the link, it redirects us to exactly what we expect. So we're going to have to make
a new test. So we're going to come here and do test. And here we're going to give this as a name
should redirect to form page on click like this, click, and we're going to give this a sync
as well a function. And here we're going to give the page and we're going to do the exact
same thing as we did before. Now the thing is, we're also going to have to write the same code
over here to actually navigate to that specific page because every single test in playwright
runs in isolation. And you have a whole new session every single time, which means you have to
reopen the browser and we go to the same page that you were before. So we have to write this again
for every single test that we want to go to this page. But doing it this way is not the recommended
way because you are repeating yourself, right, you're going to have to write this on every single
test that you want to navigate to that same page. And the truth is on the homepage in this describe
block, most of our tests, if not all of them are going to need to go to the same page. So it would
be better if you had a way to run something before every single test where we can put this little
piece of code to to make our life a little bit easier and not have to repeat ourselves.And the
cool thing about Playwright is that there actually is. We can inject the hook before every single
test, and we can put this piece of code inside of that hook. And the way that we do that is we come
here, we make a little bit of space, and inside of this describe block, because we only want this
hook to apply to any test inside of this block, that's also another use case for having describe
blocks, we're going to create a before each hook. So we're going to do test.beforeEach, and we're
going to give this here a function. So this is going to be async, like this, and it's going to
take the same page as we had before. And here, we're just going to put an arrow function,
and we're going to take this code over here, and we're going to paste it inside of this hook
over here. So now we don't need to have it inside of this individual test. And we also don't need
to have it inside of this test over here. And just to prove this to you, I'm going to comment
out this test. And I'm just going to run the test over here and run the same test. And you're going
to see that it still passes because we have this in the hook. And this runs before each individual
test. So let's come back here, let's press play. And we're going to see that this is still going
to work, because our code is exactly the same, we've now just put this in its own before each
hook, which means that if we have a second test, or any other number of tests, we don't have to
repeat ourselves every single time. And finally, let's finish up and write our test to actually
check the redirect on a specific link. So we're going to do a wait. And then let's see a wait.
And then this is going to be page get by role, we're going to give this link again, we're going
to give this name, form. And then instead of to be visible, we're going to call a different function,
we're going to call click like this, which is actually going to click on that specific input.
So then we're going to have this click. And we're going to await and expect to be on a different
page on the form page. So we're going to await, expect page to have title. And we're going to
do here form like this, because whenever we go to the actual form page, you're going to see that
the page title actually changes to form. So we're just going to check that we could also check the
URL, we could check this in a different way, if we wanted to, we're going to keep things simple. And
just check if we have the actual form over here, that's going to be enough. So let's come back
here to our actual runner. And let's run all of these tests. And now we're going to run two tests.
And we're going to see that both of them pass. So the first one still passes, that's great. And the
second one also passes, we're going to click and we're actually going to see it found that actual
element, the form element to click, you have this red little circle over here, and it clicked it,
and then it checked the actual page. And you see here we're on form, and the title is form. And
this test also passed. Great. And with this, our tests are passing, and we can guarantee and make
sure that our application is going to work exactly as we expect now. And even more importantly, if we
ever make a change to any code in the application in the future, having these tests over here is
going to make sure that if we made some code that actually break something, one of these tests is
going to break, and we're going to know about it, and we're going to be able to fix it. That's why
you want to have tests in your application to make sure that your application works as expected now,
and also in the future, if you make any changes to it. And having this in a visual runner, where you
can actually inspect every single test and go to them and actually see the UI that was rendered at
each specific step and see what the test runner is trying to click through is really, really useful.
And it's also very useful for debugging, right, whenever you're actually developing your tests and
putting them, I would recommend they use this UI because it is really useful. So now with this,
the only thing that we have to do is actually write the tests for our form page over here.
So all of these tests over here, and for this, I'm going to skip a little bit and just be faster,
because I don't want to drag this video on by just repeating the same things. But I'm going to show
you what this actually looks like for the form page. So the first thing that we want to do is we
want to create a new describe block, because now it's no longer going to be on the homepage,
it's going to be on the form page. So we're going to come here and do test dot describe. And
here we're going to do a form page like so we're going to give this a function again, and we're
going to put some code in here, we're also going to take the same describe block over here, because
we're going to want to do the same exact principle in here. But instead of going to localhost 2000,
we're going to put local host 2000 and then form so that every single test inside of this describe
block automatically starts on the form page, which is what we want. And then we're going to
come here and write our first test, which is going to be literally the same test as we had before. So
we can even copy this directly, we can come here, we can paste this, it should also have the correct
metadata and elements, but just for the form page. So in this case, the title is going to be form.
So we're going to put your form like this, the heading is going to have also form like this, it's
not going to have home page. So so we're going to save this. And then we're going to get instead
of a link, because we actually don't have a link in here, I'm going to get get by placeholder.
And over here, if I open up the form component, we have here this input, and we have a placeholder
that says enter item, we can get this input using its placeholder. And because this is the only one
that has this placeholder, this is safe to use to actually check that it is there that we have an
input with this specific placeholder. So we're going to do get by placeholder, this only takes
one argument. So we're just going to remove the second argument, and we're going to put enter item
over here. And we're going to expect that to also be visible. And finally, because we also have a
button over here that has add, we're going to do the same thing, we're going to do a wait, expect
page dot get by role. And then that's going to be button. And we're going to give it your name,
and that's going to be add and then to be visible, like so. And now we have the same test that is
testing that every single element on the screen is also visible. If you run this, we have now our
new describe block over here. So you see it's in a different section. That's one of the benefits of
using the scribe logs. And we have this test that also passes all of these elements are visible, and
they're exactly what we expect. Great. Now there's two more tests that I want to run. And the first
one is going to be that initially, whenever we load this page and refresh, refresh into it,
we should have no items displayed over here, right? That's our initial empty state. So that's
going to be one test. The second test is going to be once we actually enter an item, we're going to
check that we actually have that item over here. And that this input is clear, because remember,
if I put test, we're going to add the item, it's going to be here. And then this input is
going to be clear. That is our second test. Now to be able to do this, we're going to have to come
in here to our form component. And we're going to have to add a few properties to some elements to
be able to reference them in our test and make some expectations assertions on those specific
elements. And we're going to be making use of the data test ID attribute. So the data test ID
attribute is an attribute that you can place on any single element, it is just like any normal
prop over here. And you can give it a specific test ID. And then you can use that test ID to
reference that elements out of your test and do any single thing to it. So for example, we're
going to want to write our empty test, right, so we're going to come here and we're going to do
test. And that is going to be should have empty items list on start, right. So we're going to give
this an asynchronous function that is going to take the page over here. And this is going to be
our test that makes sure and check that whenever we're actually loading this page, initially,
we have an empty items list, and this should be empty like this. And for that, we're going to want
to get this actual element by its test ID, which we have to add over here. So we're going to want
to add it on this unordered list tag over here, because we're going to want to get this element
and make sure that its contents inside this map over here is empty, and that there's nothing. So
we're going to come here, I'm going to do data, test ID, and we're going to give this items
list like so. Now we're going to be able to come in our test and use that test ID to get this
element and make sure and check that it's empty inside. So we're going to do const items list
equals page get by test ID, as you can see here, and now we're going to give this items list,
which is the test ID that we gave it in initially in our code over here. And then the only thing
that we have to do is we have to await expect items list dot to be empty, like so we're going to
call the to be empty on the items list, we could have also done things like this, we could have put
things over here, right inside of this directly, this would have worked, I just showed you
the different way, because we are working in JavaScript and TypeScript. And we can create
variables if you wanted to. And sometimes it is useful if you want to reuse this item list in
other places. In this test, you want to create a separate variable for it so that you can then
just reuse it. So now if you go back here to our actual application, we should run this test and
it should work, it's going to get that element by its test ID. And there we go, it got the
actual element, and it saw that it was empty, which is what our test expects. So it passed our
test. There we go. And finally, the last test that we want to do is we want to check that whenever
we enter an item, and we put something in here, the item is actually added over there, and that we
have an empty input box over here. Now to do that, we're going to have to come in here to our form
again. And we're going to have to add an item over here to Li to again, get it access it in our
test and make some expectations on the search and checks to it. So we're going to do this, I'm
going to data test ID. And I'm just going to give this item like this to keep things very simple.
Then we're going to come back here to our test, we're going to create a new test test that is
going to say should add item to list that is going to be again a function a sink, we're going to get
this page like this. And then we're going to come here. And we're going to do so we're going to do
const input equals page dot get by placeholder, we're going to give this enter item like so. And
then we're going to call a function on this input, we're going to do a weight input dot fill. And
this is going to be a function that as you can see over here, we'll set a value on the input field.
This is what you use whenever you want to put text on a specific input field. So we're going to do
item one, like so. So now this input is going to have item one as its value, then we're going to
come here and we're going to await page dot get by role, we're going to get this button, we're
going to access our button and actually click it. So we're going to come here and do name. And
what happened, let's come here and do name, add, and then we're going to do click like so. And
now this is going to click the actual button, and it's going to trigger the actual functionality
that we have on a button with that specific value in the input field. So then after we click the
button, we should have our new item on the screen. So we have to get it and make sure that it has
item one, which is what we put over here as our text. So we're going to do const item equals
page dot get by test ID. And now we're going to give this item which again, remember, this is the
test ID data test ID, we gave it item. And we're also going to doAnd then we're going to put zero
because over here, this is going to be a list. So we're mapping over every single item, each item is
going to have the same test ID, and we can use the nth one. So the nth item and access the first item
in that list. So right, so that's going to be our item over here. And now that we have our item, all
we have to do is just await, expect item to have text and then item one, like so. And then we're
also going to await and then expect input to be empty. Like so because remember, every single time
that we type something that we click this button, our input should go back to being empty so that
we can type something else. So this is making that check. And then we're checking that the item
has indeed the item one text. And now with this, if I come back over here, go back to our test
runner and replay all of the tests, we should see that every single test in our application passes.
And we have our should add item to the list as passing we have over here, we're filling the
text, you can see here we have item put over here, then we're clicking the button, then we have an
item, we're getting it and we're checking that it has item one. And then we're also checking
that the input is actually empty. There you go, you are testing the entire application and every
single thing that the user can do. And you're making sure that your application is behaving
exactly as you expect end to end front end back end database involved. And that there are no
unwanted surprises. This is great. Now again, remember, this was very simple, right, you can
obviously do a lot more than this, I would highly, highly recommend that you come here and you look
at this demo app over here and actually run the application, run all of these tests, and really
look at how they're doing things. They're doing a lot more things that I did in this tutorial
video. And they have a bunch of helper functions over here that they're using across multiple
text, they're using JSON, they're doing all of those things. And this is a really great
resource to actually check and make sure that you're writing your text, your test properly, and
that you're following all the deepest practices, I would highly, highly recommend this. And also,
I would also highly recommend that you look and read the documentation of playwright because they
have a lot of examples, they have a lot of APIs and documentations that you can use to actually
write your test. Doing all of these things, you've now learned how to actually use playwright
to write your test. And more importantly, you've learned how to understand what to test and
what not to test. And you've seen a real world example of how I would approach thinking about
this and writing the actual test for a very simple application. And now you're good to go to apply
this to your own react applications and write some really cool tests and have some really
robust applications that have not one single bug in production. Let's go. If you enjoyed this
video, and you want to see more videos just like this one, make sure to leave this video a big
thumbs up. You can also click here to subscribe. Or you can click here to watch a different video
of mine that YouTube seems to think that you're really going to enjoy. And with that being said,
my name has been Darius Cosden, this is Cosden Solutions, thank you so much for watching, and
I will see you in the next video. Ciao! Ciao!
