00:00 To have this test passing, I need to make VTEST understand how to compare different measurements, even if they have different values and measurement units. To do that, I can define a custom equality tester. That function will tell the VTEST how exactly to apply this to equal matcher when we

00:15 have the received and the expected value. I will head to my test setup here at vtest.setup.ts and define a custom equality tester. To do that, I will call expect.addEqualityTester. This function is similar to expect.extend in a sense that it will customize the functionality of expect,

00:33 and it will do that in place, so we don't have to export any custom expect functions. This function accepts an array, and that array will contain my custom equality testers. So equality tester is just a function that receives two arguments. The first one is the received value, so the leftmost value, and the second one is the expected value, or the rightmost

00:52 value. So here I define my equality tester, and I will name it my measurement tester. Now that I'm done with this, in the tester function, all I have to do is to return a boolean indicating whether these two values are matching, or in other words, equal. But before I do that, I need to make sure

01:08 that both the received and the expected value is the instance of the measurement class. So I'll add a simple check, received instance of measurement, and also expected instance of measurement. And only here I will be able to compare these measurement instances correctly.

01:24 The measurement class itself happens to contain the method designed to compare different measurements, so all I have to do is to return the result of calling expected.equals to received. Once again, this equals method is implemented as a part of the measurement class, so this is my custom

01:40 functionality. And if you don't have it in your application, you can just inline it in the custom equality tester. That's also okay. So after I'm done, all I have to do is save my changes, and make sure that my setup file is properly connected to my VTEST instance, and run my tests

01:54 using npm test. So now VTEST is able to compare my measurements, even though they're different objects, structurally, because I've extended the functionality of the toEqual matcher. I introduce my custom equality tester, my measurement tester, that basically checks

02:10 if we're comparing two measurement instances, please rely on the built-in equals method of that class. And that works for nested cases as well. So here, in the second test case, I'm comparing one object to equal to a different object, and only the length properties happen to be the instances

02:26 of the measurement class. But that equality tester still applies recursively, which is really nice. So with all of this, you may be wondering, when should I reach for a custom matcher, and when I'm better off with a custom equality tester? The answer here is really simple. If you care about comparison of values, you should always use custom equality tester.

02:46 And you can reach out for a custom matcher if you need to represent a more complex logic, for example, when a single criteria of your expectation is expressed by, let's say, comparing multiple values at the same time. Also, bear in mind that custom equality testers have to be synchronous. So if you want to express custom asynchronous logic in your tests,

03:04 you should implement the custom matcher instead. In addition to that, you already know that VTEST will automatically apply a custom equality testers whenever it compares two values. And that's not the case for custom matchers. So to summarize, use custom equality testers to extend the default

03:19 equality checks in VTEST, and use custom matchers when you want to express a more complex logic in your tests.