We're now going to move on to our last drought handler which is going to deal with updating a ticket
so user is going to make a request to API tickets and then the idea the ticket they're trying to update.
That's going to be a PUT request and we're going to expect that they include the title and price that
they want to update that ticket with.
Now there's going to be some kind of restrictions on this handler that you would probably expect.
In other words you're not going to be able to access this handler if you're not authenticated.
In addition only the user who owns a ticket should be able to update it.
You're gonna have to add in a couple of different checks to watch for those things.
Now some of the tests that we've written out for these other handlers have been kind of simple and basic
in nature.
And at the end of the day were they really required.
Maybe not.
Maybe win a little bit overboard in testing some those other things.
But this put test or this update one these tests are going to be super critical Not right now but later
on INSIDE THIS PROJECT arena start to add in those other services for dealing with orders and payments
and some other stuff.
There's going to be some super critical logic around whether or not a user is allowed to update a ticket.
And so having some tests in place to make sure we've written out that business logic correctly is gonna
be very important.
They're not going to write out those tests just yet.
They're not going make any sense right now until we create those other services in the future I mean
said all that let's go and put some test together for this update root handler to back inside my error
or find the test directory.
We'll make a new file in there of update test.
Yes at the very top let's import requests from duper test and we'll get app from up up at after that
let's write out some test descriptions.
So what do we really care about here.
Well a lot of the obvious things that we kind of carried over or implemented already four tests on these
other routes.
First off if a user asked for some I.D. right here that doesn't actually exist or some ticket idea that
doesn't exist let's return a for a for if a user tries to make an update to a ticket while they're not
logged in.
Let's return a for one to say that is forbidden if a user tries to update a ticket they don't own.
Let's do a far one.
If the user doesn't provide a title or a price or a hundred invalid request and then finally if a user
does everything right.
So they're signed and they own the ticket and they provide a valid title and price.
We should make sure that the actual ticket does get updated.
So a couple of different IDs statements and total.
So first it returns a four for if these provided I.D. does not exist
I'm going to copy paste that down a couple of times like so and we'll just update the description for
each of these.
So on the next one how about returns a.
Or a one so forbidden not allowed if the user is not authenticated on the next one.
How about returns a for one if the user does not own the ticket after that.
How about returns a four hundred if the user provides an invalid title or price on previous tests.
We tried to test these things separately or in separate tests essentially this time around.
It's going to combine all into one single test.
I'm going to paste one more it down here and this will be our happy path so to speak.
So the case in which everything goes right.
They'll say it updates the ticket provided valid inputs.
Now a lot of people out there a lot of suffer engineers have a little bit more rigorous requirements
over descriptions than I do.
I am really not super picky around test descriptions.
There's definitely some people out there who are going to look at these descriptions and say it is really
unclear what you're doing with the test.
That's totally fine if you are someone who really feel strongly about test descriptions feel free to
change these.
No issue whatsoever but me personally I'm looking at these I really understand what they are trying
to convey all right let's go ahead and have a First let's deal with the 4 0 4 so I want to make a request
though await request to app I want to do a put to API tickets and once again we need to specify an idea
right here.
So once again as we saw in the last couple of videos we have to generate a valid I.D. for that we're
going to import Mongoose at the top.
I'll make up an idea right here so Mongoose types object I.D. And I want to make a new object I.D. specifically
and then off that I'm going to get or invoke to hex string
then instead of single quotes right here let's put in some back ticks.
Now I can reference I.D. inside their along with this put requests I'm going to try to include a valid
title to update this thing to any valid price but I'm not going to be logged in or see that I should
be logged in.
So let's make sure we also tag on a set cookie
and then we will expect to get a 4 is that ticket does not exist as usual if we run this test right
now.
It will pass because we don't even have a root handler for the thing.
So I won't worry about actually executing this test just yet.
Right now let's just go ahead and fill in one or two other tests about the next one returns a for one
at the user is not authenticated.
So for this well we can really just copy the exact same logic we had right above pasted in and then
instead of expecting a 4 or 4 I can expect a 4 1.
And I want to make sure that I am not authenticated in this case.
All right.
So I think that's good enough to get started and to really implement any of these other tests we might
want to try to attempt at least a little bit of implementation first.
So let's save this.
I'm going to pull back on my turn I'll make sure that these sets are at least running.
Who knows how many are going to pass or fail.
Good enough.
So quick pause right here.
We'll start to put together the implementation in the next video and start to fill out a couple more
tests.