00:00 Let's say we're testing this fetchUser function that accepts the userId and returns back the user object. And what we want to do in this test case is to make sure that this user object matches our user schema, the one we have over here. So this expectation is rather straightforward.

00:14 In fact, let's write it in human speech. So we expect the user to match the user schema. To actually implement this assertion, there's a couple of things we have to do. So first, reference the user schema and call safeParse on that schema and provide the user

00:30 object as the argument. So this is going to parse the object that we receive against the schema and give us back the parsing result. And then we have to make sure two things, that result.error is undefined and that result.data equals to the user object that we expect to be

00:48 returned from our fetch function over here. And at the surface, this achieves what we want. But let's take a closer look at what's happening. So here we have these two expect statements, which are the most important part of any test. And what we're doing here, we're asserting on the result of the parsing, on the error being undefined and on the correct data being returned.

01:06 Both of those things imply that the user object is valid, but they don't assert directly on the user object. So our expectation that we wanted the user to match the schema now becomes that we want the error to be undefined and the data to be of the following shape. We're relying too much on

01:21 the implied factor here instead of making an explicit assertion. So what we ended up doing is asserting on our test setup, on the schema parsing, instead of the user object, the data that we care about. And of course, if we want to validate more objects against their schemas, we'd have to repeat this all the time, which is also quite verbose. So there's something we can

01:41 do instead. Instead of this, it would be really nice to represent our expectations, our assertions like this. We expect the user to match schema and then user schema. This is basically one-to-one mapping of our human speech expectation over here. This reads really nicely, and this encapsulates

01:59 the criteria in a single matcher, this to match schema matcher. But what is that matcher? It doesn't really exist in VTEST... yet. In this exercise, you will be implementing that custom matcher yourself. You will tell VTEST about the call signature of your matcher on the type level

02:15 and then describe its implementation, so it validates any received data against the expected schema. You can find anything you need in the instructions, so give it your best and see you soon!