00:00 Let's start from a happy path scenario. So in this test case, I expect the order to always be created without any issues For that to happen the card items I provide have to be in stock. But of course, these are mocked items They don't actually exist in the original data source And that's great because I want to draw the test boundary at that data source

00:20 I don't want it to affect this test in any way to do that I will introduce a spy over controller and it's this item in stock method And if I leave it at this Vetus will still spy on this method being called But it will actually call its original implementation and test as well

00:37 That's precisely what I want to avoid to do that. I will call mock return value This method accepts the value and I will use true What's going to happen with this is when create order method bubbles to call is item in stock Instead of calling the original implementation of this method in the order controller class

00:56 Vetus will call this mock function that always returns true in other words in the context of this test we just pin the behavior of this method to always treat any card item as being in stock and With that I can conclude the assertion that I expect the order to equal to this particular order including the cart

01:16 I like being explicit in my assertions. So I will just copy the whole cart array as is And notice that I'm providing this order type argument to the to equal assertion this way this expected order is type safe So if I forget to include let's say cart ID typescript will let me know about it in a similar fashion

01:35 I can complete the error scenario, but it will be a little different So here I have a cart items with IDs four five and six in total three cart items And what I will do here, I will still introduce a spy on the controller and it is item in stock method

01:52 But instead of just pinning it to particular mock return value I will replace its entire implementation by calling mock implementation and it will accept this function as an argument It will replace the implementation of this method in test It still has the same call signature

02:11 So it accepts item and in the implementation I will treat only the item with ID that equals four as being in stock and this is why I do it So if I only treat this first item as being in stock I'm able to reliably reproduce that the other two items and their IDs will be present in the error message

02:29 Thrown by the order controller instance. So let's verify just that I will add this assertion spec statement and I will expect that creating order with this cart will throw an error message That includes items five and six as being out of stock. Let's verify that by running NPM test. So NPM test

02:52 And I can see both heavy path and error scenario passing So what we're doing in this particular exercise still introducing a spy over this method of our controller class But instead of letting betas to execute that method as is We're using functions like mock return value to pin the return value to particular

03:10 value like true here to always treat any card item as being in stock or Mock implementation that completely replaces the original implementation with this mock function in this case to trigger different conditional scenarios