Inside of our roots file we're gonna find our update dot t s file.
This is the root handler that handles updates to tickets.
So as I just mentioned we need to take a look at the ticket that the user is trying to update and if
it is currently reserved or locked down we need to reject the update request to do so.
We're gonna scroll down a little bit inside of here and then right after we find the ticket and it can
be right before or after we take a look at who owns the ticket to somewhere inside of here we need to
decide whether or not we should allow the ticket to be edited in case it is actually reserved.
How about right after we find the ticket we'll say if ticket court order I.D..
And that's pretty much the check.
No we had said the presence of an order I.D. means this thing is reserved and we should prevent edits.
So if there is an order I.D. fantastic let's throw a new air I think the most appropriate air here would
be a bad request error.
So I'll throw a new bad Request air.
We do have to import that at the very top from our common module I will get bad.
Request air and that should just be about it.
One thing we forgot we have to provide a message here.
So some explanation.
Well we can give a very simple explanation.
We can say ticket is reserved or how about an edit a reserved ticket.
Simple enough.
ALEX Good.
Now as I mentioned I would really like to write out a test around this as well just to make sure that
we've got something to say yet we cannot edit a ticket.
Naturally the logic here is really simple and straightforward.
So the test is a little bit over the top.
Nonetheless this is the kind of thing you want to test because this is some pretty critical business
logic so inside of our test directory inside the Reds FOLDER WE'LL FIND update test.
Yes
let's then go down to the very bottom and we'll add in a new test it will say it rejects updates if
the ticket is reserved
let's then get a very quick reminder on how we write out tests around row handlers because it has been
a while since we've done that.
So I can take a look at our previous test in the previous test.
We first created a cookie so we can make a number of requests as one consistent user.
We then created a ticket and then made a follow up request to edit that ticket so our test is going
to be very similar except we're going to expect the follow up edit to result in a 400 or essentially
a bad request.
In addition in between the creation and the update we're also going to have to reach directly into our
database get a handle on the ticket that was created and set the order items property on that thing
as well.
Now just to save a little bit of time from this previous event or some previous test publishes an event
I'm going to copy the cookie the request to create the ticket and then default request to edit it as
well.
So going to copy those three blocks right there and then paste them down inside of our test and we'll
just make a couple of changes to this thing so first off we do know that our follow up request right
here we are going to expect to get back a 400 in addition we're going to make sure that right after
we make this initial request for the penguin to reach in find our ticket and set the order items property
on it and to do that we're going to first off have to get access to our ticket collection.
Number two we're also going to need access to Mongoose so we can generate a random I.D. or the order
idea as well so at the very top looks like we've already got an import for mongoose.
I'm going to add in an import or ticket as well from.
Up one to models.
Oh come on
all right.
Back down at our test right after we create our ticket well then do a ticket and that's going to come
from a weight ticket defined by Idi and the idea of the ticket that we are looking for is inside the
body of this response right here.
So it's going to be a response not body that.
Then we'll do a ticket set of the order.
Idi and we're going to set it to a mongoose that types object IDI to hex string and as usual good throw
a exclamation right after ticket right there as well.
And then finally let's make sure we do in a weight ticket that saved and another darn exclamation.
There we go again.
So that's pretty much it.
We got our consistent user rate the ticket edit it save it make the following request expect that request
to air.
Let's save this and see how we're doing.
I'll go back over to my terminal and find my test suite.
Now we are still filtering our tests so I'm going to hit W to go to the watch menu and then going to
filter by file name once again by hitting P and I went to tried to run only this update test file.
It's all but an update dot test case looks like I'm writing or running the correct file and it looks
like all of our tests are passing as usual.
Just quickly make sure this thing is failing as expected.
So what happens if we come into all that stuff out and never set the order I.D. property.
Well now our request should succeed with a 200 and so we got a 200 back when we were expecting a 400.
That means that our test is failing as expected.
So uncommon that looks like everything is going.
Now I'll do just one last test run of all my tests inside of this project by hitting W and then a and
we'll just make sure that the entire service is good to go.
Yep looks like it is.
Well that is it.
So I think we're all set here.
Quick pass.
Continue in just a minute.