Loading
Current section: Debugging Tests 5 exercises
Problem

DOM Snapshots

Loading exercise

Transcript

00:00 The majority of your component test will consist of rendering the UI, like I have this tic-tac-toe game here, interacting with it to bring it into a different state, and asserting on that end state. And usually your test fails because one of those assertions threw an error. The assertions themselves are not to blame, they're simply expectation checks to let you know that

00:19 hey, something's wrong. The issue is likely somewhere in the previous steps. Either the component rendered incorrectly to begin with, or some of the interactions did not produce quite the result you expected. What makes debugging component tests especially tricky is that you don't always know the state of the DOM. You have your component's implementation, but that doesn't

00:37 necessarily translate one-to-one to what gets rendered on the page. Well, because you can have elements added conditionally or dynamically, in response to user interactions or maybe some side effects. This is where being able to print the current state of the DOM at any point in test comes as a huge time saver. And that's exactly what you're going to do in this exercise.

00:56 Because you see, I have an automated test for this game that interacts with it and expects to have a horizontal line of crosses. But when I run this test, it tells me that instead of three crosses, I have only two, and the third one is missing. And that is definitely a bug. Your task in this exercise is to use the built-in tools in Vitest

01:16 to print the current state of the DOM after the test interacts with the game. Hopefully that will give you some idea of what's wrong, so you can fix the issue and have the test passing.