Let's move on to our three remaining tests here.
The next one we're going to try to create a ticket and then update it with a different user that should
return a status could afford one.
Now this is going to be just a little bit more tricky than it might appear at first glance.
Remember how I said that it's kind of nice to create a ticket by making an actual request to our ticket
creation end point.
So in other words we're going to want to write in some initial logic inside of here to create a ticket
like this.
We're going to want to do something that says request to at make a post to API tickets set the cookie
with global sign in and we'll send along some title of whatever and price of about 20 that will create
some initial ticket that we can then tried to edit and here's the key thing when we actually create
this ticket the ticket is going to have a user I.D. equal to whatever user I.D. is extracted from the
cookie that we include were then ideally going to want to make some kind of follow up request right
here.
That's going to attempt to edit this ticket that's been created.
And when we make this follow up request we're going to try to use the same exact cookie.
It's going to have the same user I.D. inside there.
And so right now we only have essentially exactly one user I.D. floating around the entire application
so we can't really fake being a different user who does not own the ticket to solve this.
Let's go back over to our setup test file then cited my test directory.
I'll find setup test but here's the sine function.
And right here is where we set the I.D..
So again that I.D. is hardcoded for every single user that we tried to authenticate as inside of our
test environment.
So to fix this problem up I think we should just very simply randomly generate an I.D. whenever we call
sign it.
So every single time we call sign in we're going to pretend we are just an entirely different user.
Now what if we need to make the same request or make two different quests as the same user in a row.
No problem.
We can just call sign and once save a reference to the cookie that gets returned and then make as many
requests as that user as we wish.
So not the worst thing in the world to randomly generate this idea let's use that same kind of object
I.D. thing that we saw from Mongoose that we've now used once or twice before.
We've already imported Mongoose into this file.
Right there we should be able to very easily replace that hardcoded I.D. with new Mongoose types object
I.D. to X string.
All right.
So I should definitely work now back inside of my update test file.
I've got one request right here that is going to attempt to rate the ticket when we make this request
that ticket is going to be assigned some I.D. We need to capture that I.D. so that we can somehow make
a followup request specifying the same I.D..
So in short I'm gonna make sure that I capture the response that comes back.
Then after that I will attempt to create another request right here.
So another await request to app.
This one is gonna be our actual edit request.
So I need to make sure that when I do this put I specify using a template string.
So back to X right there API tickets and then the idea of the ticket we had just created the response
body.
We're not going to pretend that we're a totally different user so we'll set our cookie and call global
signed in a second time when we call it a second time.
We'll now have a new randomly generated I.D..
So as far as our app is concerned we are trying to access the thing as a different user then go ahead
and send the update.
I want to make now how we update this thing not super relevant.
All we need to do here is make sure we provide some valid title and price doll put in a title of some
new random string and some new price unity.
We really care about here is that we get back a for one and that the update gets rejected.
So I will expect a 4 1.
Now one thing we could obviously do here after making this request we're only checking to see that we
get a 4 1.
If we had some pretty broken code we might mistakenly send back a for one and still process the update
anyways so optionally you could do a follow up request to retrieve details about this ticket and verify
that it has the same title and the same price just to make sure that the update was truly not processed.
If you want to do that feel free to do so.
Otherwise this is pretty much good for me.
So I have to say this.
Let's go back over to update and we'll put together our implementation tobacco over here.
We're going to assume that if we are trying to update the ticket we hopefully have found one successfully.
So we'll get past that if statement so after that we're going to check and make sure that whoever's
making this request it has the same I.D. as the user I.D. it saved on the ticket will say if ticket
dot user I.D. is not equal to wreck dot or user dot I.D. then let's throw a new not authorized air once
again we're running to that same issue we've seen several times before where we definitely are setting
the current user property because we've gotten past that require check what typescript doesn't really
believe it.
So we'll title typescript don't sweat it.
We already made sure current user was defined inside that middleware.
We're gonna do that by putting on that exclamation.
So this looks good.
Let's say this ANSI our tests are doing
tobacco over here.
OK everything's passing now at this point.
We kind of never really saw that test failed.
So for all we know writing in this implementation might not have actually made the test pass our test
might be in itself faulty.
So one thing I kind of like to do that we've really been neglecting in all the tests we've run out so
far is comment.
That's this thing out and make sure that our test actually does fail at least one time.
So I'm going to count that out.
I'm going to say this I got to make sure that test fails yeah definitely does.
So we got a 200 instead of the expected for one unauthorized.
That means that the test is working as expected.
I'm going to uncommon that again.
And there we go.
So just a little bit more.
We're going to handle the case in which we have an invalid title or price and the actual success path
as well.
We're gonna take care of those of both those in the next video.