Let's write out a quick test or two around this delete root handler inside my underscore and a score
test directory will make a new file of delete test 2 Yes.
Then at the very top let's get request from Super Test as usual app from up to directories app and I
think we probably need our ticket model as well.
Talk to directories models ticket then inside of here what do we really want to test.
Well naturally vary so much in some of the root handlers we already tested.
We might want to make sure that the order that the user is looking for actually exists.
So we might want to try to send in request and try to update an order that doesn't exist at all and
make sure we get back a form of 4.
We could make sure that this thing is only accessible if the user is authenticated.
We can write a test to make sure the order I.D. parameter looks valid.
We could write out a test to make sure that the user is the owner of the order as well.
These are all things we could definitely test but just to stay focused on what we're doing here.
We've seen an example of all those different tests so you can copy paste them over and implement them.
For this handler if you want to but you and I together in this video are just going to really focus
on the success case.
We're gonna make sure that a order can be created and then make sure that we can make a file of requests
to delete it.
And that's pretty much it so for the one test we're gonna write out inside of here.
We'll give a description of it marks an order as not deleted but really cancelled.
So I will still put in a couple of comments just to guide ourselves here.
We're going to create a ticket with ticket model well then make a request to create an order.
Well then make a request to cancel the order and then finally we'll write out some kind of expectation
to make sure the thing is cancelled.
That's pretty much it.
So kind of another multi-stage test to put together here.
So first off create the ticket.
We've done this many times before.
So a ticket dot builds with a title a price save it to the database.
No problem.
When we make the request to create the order and then the follow up requests you cancel the order need
to make sure that those requests are being issued as the same user.
So once again we'll create a single user cookie here
and we can reuse it over both those requests.
So first request we'll do and await request app.
We want to do a post to create an order so that's going to be a post to API orders set are cookie send
along the ticket i.e. or the idea that ticket to be created right up here.
That'll be ticket.
I.D. is ticket dot i.e. and again we'll just make sure this thing was actually created.
So expect a 2 a 1 when we make the followup request to cancel the order.
We need to know the idea of the order that we had just created in the previous step.
So once again we'll d structure out the body and I'm going to rename that on the fly to a variable of
order.
So just using the same technique we saw a moment moments ago that's now we can try to cancel the order
we'll do and await requests to app.
Once again this time we're gonna make a delete request to API orders.
Died of a string.
We need to put the idea inside of here.
So let's do a little bit of string templating again.
So you some back ticks and at the end of that string we'll put in our order i.e.
we need to make sure that we make this request has the same user so against that the cookie using the
user that we had generated up here
we'll send it and finally we'll expect it to A4 because that should have all worked successfully so
having just the two a four right here could in theory be enough to say everything went.
Expected as expected because we did get down to the bottom of this handler but once again we're not
really writing out an expectation just yet where we actually reach into the database.
Take a look at that order and make sure that it's order status was updated canceled.
So again if we run this test right now it will probably pass but we could potentially have some other
engineer come inside of here completely mess up those two lines of code and the test would still pass
probably erroneously.
So going to say yeah let's just go through that extra step let's try to fetch the order that had been
created out of our database.
We're then going to take a look at its status property and just make sure it was updated to cancelled.
So to fetch this order out of the database or you know another way to implement this just to mention
it really quickly we can always try to also fetch that order through the show handler that would work
as well either way.
Totally fine.
Let's go with just fetching the word out of the database at the very top.
We'll get our order in order status.
Enum
then back down the bottom.
We'll get our How about we call this updated order from a weight ordered out find by I.T. and then we'll
stick in the order.
We're going to get back the updated order in all we really care about here is taking a look at the status
making sure it is equal to order stored as status got cancelled that's it.
So we can write out an expectation expect updated order status to equal order status not canceled
and I'm getting an error right here because it is possible that update order is not defined so tell
you what we'll use the exclamation here once again and just tell typescript Hey don't sweat it if we
fail to actually find the order out of the database from this line right here then this line of code
or see this line of code right here the actual expectation is going to fail because we're going to try
to look up property status on a value of no and that will cause this test to throw an error and fail
so it's okay here to put the exclamation because we kind of want this thing to fail if for some reason
we fail to find the order in the database.
So in this scenario I think it's okay to use the exclamation but if this was some actual app related
code or code we wanted to write instead of request handler we should definitely add in a check to make
sure that we did find in order but again in a test in setting.
This is actually kind of what we would want to have happen we would want to see this blow up to some
degree all right let's say this go back over to our terminal see how we're doing.
There's my delete test right there and it looks like we are passing go now we've got this delete request
handler all put together but there's one other thing we should probably just think about really quickly
at some point time inside of here we are changing the status of an order that's a pretty significant
event inside of application if there are any pending payments that we're waiting for a user to send
over to us or if there is a pending expiration order or whatever else chances are we need to tell other
parts of application that this order was just cancelled so in other words right after we successfully
save this order to the database we probably should be publishing an event saying this was cancelled
we've already got a event very similar to this back inside of our new handler where we said we're going
to come back and take care of it of in a little bit and remember what we did to kind of have a reminder
that we had to update that new request handler we put in one of those X it tests inside of our test
file or me it was a to do test we made the to do test to say oh there's something we still had to come
back and take care of let's do the same.
In this case as well in our delete test file I'm going to go down to the bottom and I'll say it emits
a order canceled event and I going to mark that as it dot to do and so that's going to be kind of our
sign here something just remind us we do have to come back and take care of something inside of here.
So I should see that we have two pending to DOS or those two different events so we still need to implement.
All right.
That's pretty much it for our basic root handlers.
We've got our four different handlers.
We have not really tested these inside the browser they're not hooked up to the react app or anything
like that but because we have our test suite running I'm pretty confident that everything is going to
work as expected.
So at this point the next thing we really have to do is think about events inside the service remember
events inside of our order service are going to be very tightly couple to a degree as tightly coupled
as events are over to our ticket service.
So we really need to get a good understanding of how these two services are communicating and the exact
events that are going to be shared between the two.
So let's start to take a look a deeper look at all this the venting stuff inside of our particular application
in just a moment.