00:00 Imagine your test as a conveyor belt, so you put your function or component or the entire app on one end and then it just drives through and your test interacts with that app, puts it in the correct state, and then you have your quality assurance line, your assertions. And every assertion is like a person, and they check a specific thing. And as soon as that tested system,

00:19 your app, doesn't pass that quality check, that person takes your app and just pulls it off the conveyor because it's not ready, it's not correct. That's a great characteristic of automated tests because it allows you to fail fast and as soon as you spot an issue, stop the test run. This kind of assertion is also referred to as hard assertion because as soon as it fails, nothing

00:38 past that assertion will run in your test. Your test will basically short circuit. And that's great because we write tests for them to fail, but it matters a lot when and how they fail. For example, let's say I'm testing this data and I want to make sure that it's an area with three elements and then those elements equal to particular values. So if the actual data happened

00:57 to be malformed, like missing this third element, and I run this test, what will happen is that the test will fail, of course, because this first assertion that checks the array length will say that it expects three elements, but it got only two. This is useful, but it can be much more useful

01:15 because simply printing the wrong array length is not enough information for me to reliably understand what was the root cause for this issue. And because this is a hard assertion, then obviously nothing past this assertion runs, so this equality check never executed, and I don't even know what are the

01:30 values of my data. In this situation, the solution would be to rely on implicit assertions. In other words, if I'm already checking the strict equality of my array to have three elements with these values, I don't have to check the length before this. The length would be implied by the equality

01:46 check. So that would be enough for me just to have one assertion, and now when this one fails, I can see a nice diff that will hopefully let me know more information to debug this failure. Implicit assertions are great, but sometimes they won't cut it. Sometimes you're expressing a lot of things, a lot of expectations towards your system, and you really want to run all of them, or maybe a subset

02:06 of them, and only then fail your test. That kind of assertion is called a soft assertion, and in contrast to the hard assertion, when it fails, it doesn't stop your test. It actually continues the test run, and only once your test function is done, then it will fail your test and print all the failed soft assertions. The concept of a soft assertion is nothing new. It existed in other

02:25 programming languages for decades now, but somehow never found its practical application in JavaScript. Well, that changes now because Vitas ships first-class support for soft assertions, and you've guessed it. In this exercise, you will be learning how to use soft assertions to your advantage. I've got an automated test for you, and it's failing, but before you go and fix it, try to

02:44 refactor this test from hard assertions to soft assertions, and see how can that give you more information about that failure, and then make sure that the tests are passing. So, give it your best, and see you once you're done.