00:00 In this one, we are testing this FetchTransaction function that accepts the transaction ID as an argument and then returns the promise that eventually resolves to this transaction object. If we take a look at this object, it's described in this interface, we can see that it has properties ID of type string, issuer of the type user, and the recipient also of the type user.

00:18 It's important to keep the shape of this object in mind when writing assertions for the return transaction. So let's do just that. Here we will write that we expect our transaction to equal to the exact transaction object. So having the ID, the same ID we passed as an argument, and the issuer, and then the recipient. You can see that right now,

00:39 we don't have any type intellisense telling us that we're actually providing invalid values for these properties. To fix this, we can provide a type argument to this to equal matcher of our transaction interface. This way we're annotating the expected value here and TypeScript starts warning us, hey, we're not actually providing the correct types here.

00:58 So here we would need to compare that these properties, the issuer and the recipient match the user schema. So normally using the symmetric assertion, we would compare some sort of value to match schema to another value. But we can do it here because we nested in another matcher, this to equal matcher. This is where you reach out for asymmetric matchers.

01:20 And we can say that we expect the issuer property, expects to match schema, user schema, and do the same for the recipient here. And we can see that the types here now match. And now let's run the test to make sure that they're passing. So npm test, and yep, we can see this scenario being successful. One thing you probably noticed

01:39 is that we're not doing anything special for the VTest to turn our custom matcher into an asymmetric one. And that's because when we are extending our matchers over here, VTest automatically uses our to match schema implementation for both the symmetric and asymmetric variants of the same matcher. What's even better is that we can have the type safe experience here

01:59 because VTest knows that we expect a Zot Schema because when we extend this matchers interface, it automatically augments both symmetric and asymmetric type definitions with our custom matchers. And that's really handy. If for some reason you want your custom matcher to be available only as a symmetric, you can also extend the interface

02:18 that's called asymmetric matchers containing. And of course, add your own custom matchers interface here. But keep in mind that this will only market as asymmetric on the type level. On runtime, you would still be able to use this matcher in a symmetric variant as well. Asymmetric matchers are a great way for you to be even more expressive in your assertions,

02:36 especially because you can use them nested in other matchers.