In this video we will take a look at how to debug our failing
test right in VS Code as well as debugging using the trace
viewer.
Let's dive in and find those bugs.
Let's break our test by making a simple typo and changing the
remove button to be called removed.
Let's make sure we have Show Browser checked and then run our
test.
As expected, our test fails because we have Show Browser
checked.
We have access to the browser window and now in VS Code we can
click on each line of our test to see the locator highlighted
in the browser.
Yet where the test is failing we can see no element is
highlighted because Playwright can't find that element.
By removing the letter D from remove we can now see our
locator highlighted in the browser, meaning playwright can
find it.
You can see if we remove even more letters and have only the
letters of or E, it will tell us that there are more than one of
these locators.
By scrolling down the page we can see that this matches the
refund policy in the footer of the page.
This would mean that this is not a very good locator and your
test would fail as playwright is strict by default and therefore
can only accept one matching locator.
As playwright doesn't know which one it should click on, it fails
the test.
This is why it is important to always choose good locators that
have exact matches.
Check out the Locator docs for more info on how to create exact
matches and also use chaining and filtering in VS Code.
We can also set break points by clicking next to the line we
want to pause our test on.
You will see a red dot appear.
We can then run our test in debug mode by right clicking on
what was previously the play button, but it's now a red X.
Then from the drop down menu select debug test.
You can also click on the debug test icon next to the test name
in the testing sidebar.
Now in our browser window you will see our test has stopped on
the element and it's highlighting the name we have in
our test and that playwright has found two elements with the same
name.
If we click on the play button of our debug menu, the test will
give us the strict mode violation error.
We can then fix the error by changing the name to remove and
rerunning our test in debug mode.
Now we can see we only have one element found for that locator
and pressing play will continue to run our test and our test
will pass.
We can now remove the break point by clicking on the red
dot.
Another way to debug your test is by using the trace viewer.
First, let's break our test again.
This time let's change line 12 and instead of the label Cart,
let's change it to bag.
Now let's go to our testing sidebar and click on the Show
Trace Viewer option and then run our test as normal.
Playwright will try to find the element with the label bag and
will retry it until the time out has reached.
After the default of 30 seconds it will show us a trace of the
test up until the moment it fails.
We can now walk through our test step by step to try to
understand what went wrong and why.
If we click on the source of our test in the menu on the right
side, we can see each line of code as we click on each action
of the test.
Line 12 is underlined in red and this is where our test is
failing.
Playwright is waiting for an element with a label of bag and
can't find it.
We also can't see a label of bag on the page as we can just see
an icon and it looks pretty much like a bag to us.
However, we can easily check what the correct locator is for
this bag by clicking on the pic locator button and hovering over
the bag icon.
We can see that under the bag icon the locator is highlighted
and it is in fact a get by label cart, not bag.
If we click on this element it will add the locator into the
pic locator box.
We can then use the copy button on the right hand side to copy
it to our clipboard.
Now in VS Code we can go to line 12 where our test is failing and
replace the locator with the locator we have just copied from
the trace viewer.
We can then save our test and rerun it and as you can see our
test now passes and playwright can find our element and it is
being clicked on just like expected and the test continues.
As we click on each action we can see the element highlighted
in the Dom snapshot and we can even see what happened before
this action and what happened after it.
Don't forget if we need to inspect the HTML or CSS of our
code we can simply click on the pop out button to pop out our
Dom snapshot into browser window and then open dev tools by right
clicking on the browser window and choosing inspect.
We can then easily understand where our cart label is coming
from.
In our case, the word cart is coming from the area label of
the button.
We can then decide if we want to change this label in our code or
just modify our test to use the word cart instead of bag.
Now that we know how to debug our tests, it's time to run our
tests on continuous integration so that tests run on each comet
and pull request.
By running our tests on CI, it means that all bugs will be
caught before they make it to production.
Nice.
See you in the next video.