WEBVTT 00:00.000 --> 00:04.560 Okay, now that we've got our controller with its endpoints, now it's time to go and test our order 00:04.560 --> 00:08.220 creation and our ability to go and get the orders as well. 00:08.250 --> 00:12.750 Now, if we go and take a look at section 11 in postman, we do have some requests. 00:12.750 --> 00:17.130 We've got one to create an order and one to get orders and get order details. 00:17.130 --> 00:19.800 But we need a basket or make sure we have a basket. 00:19.800 --> 00:25.680 And inside section ten, let's just log in and make sure we've got a fresh cookie stored inside postman 00:25.680 --> 00:27.420 for Bob at Test.com. 00:27.420 --> 00:31.170 And if we take a look at getting the basket, see if we've got a cookie. 00:31.170 --> 00:33.870 Still in postman for this I do. 00:33.870 --> 00:38.310 And I've also got a payment intent ID for this one. 00:39.420 --> 00:44.520 Now, is there going to be any point where we create an order where we do not have the payment intent 00:44.520 --> 00:44.940 ID? 00:45.060 --> 00:46.410 I think not. 00:46.440 --> 00:55.080 In fact, I'm so certain of this that I'm questioning why in the order I made the payment intent ID 00:55.110 --> 01:00.510 optional because there should be no occasion where we create an order without there prior to that, 01:00.510 --> 01:03.210 the payment intent ID being created. 01:03.210 --> 01:05.100 So I'm going to set this to required. 01:05.100 --> 01:12.060 Now this is an entity, and I'm not 100% sure if this is going to require an update to the database 01:12.060 --> 01:12.570 schema. 01:12.600 --> 01:15.570 I've also got a warning in the orders controller. 01:15.960 --> 01:25.560 And the reason for that is that the order is using the payment intent ID, but because it is optional 01:25.560 --> 01:30.150 in the basket and it needs to be optional in the basket, then that's something that we're going to 01:30.150 --> 01:34.260 need to check for higher up to make sure we have this before we do attempt to create the order. 01:34.260 --> 01:44.310 So I'm just going to make an adjustment inside here as well and say or and we'll use not string is null 01:44.310 --> 01:48.570 or empty for the basket dot payment intent ID as well. 01:48.570 --> 01:53.520 So we'll just add that check as a third check before we attempt to create an order. 01:53.520 --> 01:58.950 And that should mean and I need to take out the knots there because we're checking to see if that is 01:58.950 --> 01:59.910 null or empty. 01:59.910 --> 02:03.450 And that should mean that our order controller is now clean. 02:03.480 --> 02:08.700 Now, in order to make sure or check to see if we need to update our database schema, we'll just try 02:08.700 --> 02:10.320 and create a new migration here. 02:10.350 --> 02:14.070 So inside the API tab I'm just going to stop the API. 02:14.100 --> 02:22.500 And I'm just going to say dotnet f migrations and order entity updated and press return. 02:22.500 --> 02:27.360 And I just want to check to see if there's anything that does need to change with our database schema. 02:27.390 --> 02:31.710 Now it tells us that an operation was scaffolded that may result in the loss of data. 02:31.710 --> 02:38.310 And that's possible if we had any orders that did not have the payment intent ID set inside our table. 02:38.310 --> 02:44.130 But we haven't created any orders yet, so we're perfectly okay with ignoring that if we go and check 02:44.130 --> 02:44.970 the migration. 02:44.970 --> 02:50.940 I just want to see if there are any changes that are included with this migration. 02:50.940 --> 02:51.990 And sure, there is. 02:51.990 --> 02:54.600 So we do need to apply this to our database. 02:54.600 --> 03:02.280 So it's just going to alter the column and make our payment intent ID not allowed to be nullable. 03:02.280 --> 03:02.910 So that's fine. 03:02.910 --> 03:07.320 We can just restart our app and that will be applied to our database. 03:07.320 --> 03:14.400 So I'm going to go ahead and do that and execute dotnet watch and apply that updated migration to the 03:14.400 --> 03:18.960 database and to make sure our app starts without any errors as well. 03:18.990 --> 03:19.530 Of course. 03:19.560 --> 03:20.580 Okay, so that's fine. 03:20.580 --> 03:26.280 Now we can go test and I've got a basket with a payment intent ID. 03:26.490 --> 03:27.120 Great. 03:27.120 --> 03:35.460 And if we go and take a look at the create order, then what we have here is the properties that make 03:35.460 --> 03:37.050 up our create order DTO. 03:37.080 --> 03:42.420 We've got our shipping address with its properties and we've got our payment summary with its properties 03:42.420 --> 03:42.870 as well. 03:42.870 --> 03:45.690 And that's what we need to create the order. 03:45.720 --> 03:47.190 Now I'm just going to click send. 03:47.220 --> 03:50.820 Please do feel free to practice running through this with the debugger. 03:50.850 --> 03:54.660 We've done this a few times on this course so I'm not going to demonstrate this again now. 03:54.660 --> 04:01.290 But if you do want to see this request happen more slowly, then please do pause the video and run it 04:01.290 --> 04:02.940 through the debugger if you wish to do so. 04:02.940 --> 04:09.810 To give yourself some practice using that, I'm going to just click send on this occasion, and I have 04:09.810 --> 04:16.470 a bad request and it tells us that the shipping address is missing the postal code. 04:16.470 --> 04:24.550 And inside here You won't face this problem because I live adjusted it inside here we've got our postal 04:24.550 --> 04:26.920 code as underscore postal code. 04:26.920 --> 04:29.740 So I'm just making that small adjustment inside here. 04:30.730 --> 04:32.800 And let's rerun that request. 04:32.800 --> 04:34.000 I'll click send again. 04:34.000 --> 04:36.790 And this time we get the 201 created. 04:36.790 --> 04:43.210 And if we take a look and see that we have our order not shaped quite how I'd like it, but it doesn't 04:43.210 --> 04:49.930 look like we've got the object cycle detected error because we can only see one round of this if I just 04:49.930 --> 04:51.340 double check the API as well. 04:51.370 --> 04:55.570 Make sure there's no errors after that request, that looks fine as well. 04:55.780 --> 05:00.070 It's not shaped quite how I want it, so we will do some shaping soon. 05:00.070 --> 05:02.200 But we do have our order being created. 05:02.200 --> 05:03.640 We can see the ID is one. 05:03.640 --> 05:04.900 We've got the buyer email. 05:04.930 --> 05:07.270 The shipping address is what we sent up anyway. 05:07.270 --> 05:09.040 We've got our order date. 05:09.220 --> 05:10.990 We've got the order items. 05:10.990 --> 05:12.670 We have our subtotal. 05:13.540 --> 05:19.780 We have our delivery fee, which is set to zero because the order is $900 in this case. 05:19.990 --> 05:25.410 And we've got our payment intent ID, etc. and the order status is coming back as zero. 05:25.440 --> 05:31.500 Now that's the first item in our order status enum, but I'd prefer that to specify as pending rather 05:31.500 --> 05:32.400 than just a number there. 05:32.430 --> 05:33.240 That's the default. 05:33.270 --> 05:36.120 How this gets returned to us. 05:36.390 --> 05:38.730 And then we've got the payment summary as well. 05:38.730 --> 05:41.670 And if I take a look at getting the orders then click send. 05:41.670 --> 05:43.140 We should get the order back. 05:43.140 --> 05:44.130 And we do. 05:44.160 --> 05:49.230 And if we get the order details well we've only got one order but it's orders forward slash one. 05:49.260 --> 05:50.370 I'll click send on this. 05:50.370 --> 05:52.890 And we've got our order being returned. 05:52.920 --> 05:54.060 Marvellous. 05:54.060 --> 05:57.540 But like I mentioned I don't particularly like the shape of the data. 05:57.570 --> 06:05.670 We've got an issue here with the order items in the details and in not in the list. 06:05.670 --> 06:07.050 That's interesting. 06:07.140 --> 06:10.200 So we've got something to look at with the order details. 06:10.200 --> 06:11.250 There's something different there. 06:11.280 --> 06:15.120 We're obviously not getting the item or the order back with the items. 06:15.120 --> 06:21.450 And I'd like to shape the data a bit more client side friendly as well. 06:21.480 --> 06:26.340 So when it comes to using this, it just makes it easier for us to update the user interface. 06:26.340 --> 06:29.880 And we'll take a look at shaping this order data next.