Let's take care of the validation test and the actual success case as well.
In this video that we should build to get through it pretty quickly to first get started by writing
in a test here or doing some validation.
So as usual I do need to make sure that a ticket actually already exists.
So go back up to the previous test.
I'm going to copy that creation logic right there and I'll put it down inside of here like so now in
this case we want to make a request ask the same user who we were when we created the ticket.
So I going to save a reference to the cookie that we're generating right here so that I can pretend
to be the same user over multiple requests.
So I going to cut out that global dot sign in and right above I'll say cookie is global sign and and
I'll stick the cookie in there OK.
So we are creating that ticket.
Now I want to try to make some requests to update the thing and as we try to update it we're going to
put in some invalid values inside of here.
We're just going to write out an assertion to say that we get back some kind of error saying hey sorry
four hundred you provided us some bad inputs so we'll do an a wait request to app once again we want
to do a put request to a very specific ticket.
So I going to use those tactics.
Put in API tickets and then it will stick in the I.D. from the ticket that was created and we get that
out of the response the response body I.D. will then set the cookie so that I am the exact same user
and then let's send along How about an invalid title and I'll stick with the same price of 20 so in
this case.
Well we want to make sure every ticket always has a title that some value inside of it.
So I'm going to expect to get back a 400 we could definitely do another follow up one to make sure that
we get a four hundred if the title does not exist.
If you want to write out that test totally fine.
Otherwise I'll just do another check to make sure that a price that is invalid results in at 400 as
well.
So I'm going to copy that request
paste it down below.
In this case I'll put in a valid title but an invalid price so price is going to invalid if it is in
the negatives so negative 10.
That's your work just fine.
All right as usual I will say this in a flip back over
and now it looks like we do have a failing test which is good in this case the reason it's failing is
that you and I expected to see a 400 but instead we got a 200.
So right now we're erroneously sending back a 200 even though we put in some very bad inputs.
So let's now go add in some validation steps and we're going to make sure that that 200 that we get
turns into a 400.
All right.
Back over inside of my update file.
We definitely need to do some validation.
Luckily we've already imported body and validate requests so right after our require off middleware
let's put in an array we're gonna write out our different validators in here and then after that array
I'll make sure right away that I add in the validate request middleware so validate requests and we'll
do some checks on the incoming body.
So first we will check our title and just like we had in our creation steps we'll pretty much just make
sure that this thing exists.
So not is empty has a message of title is required and then check out our price and for this let's make
sure that we've got a float here and we want to make sure it's greater than 0 with a message of price
must be provided and must be greater than zero.
I think we use a better message back in our creation handler if we want to go look up that error message
and use a consistent one.
Feel free to do so okay.
So that looks good.
Let's say this rerun our tests back over here everything's passing.
Very good.
Now just one last thing to do.
Let's make sure that we actually can update a ticket the very last test down here as usual.
Once again we need to create a ticket ahead of time so we can actually edit it.
I'm going to do a little bit of copy paste from the test right above.
So from the one we were just working on I'm going to grab where recreate the cookie and then make the
initial ticket copy all that go down to our happy path right here.
Pace that in and let's try to edit the ticket.
So we'll do and await.
Request to app.
I'm gonna do a not opposed but a put and once again we're gonna use some string interpolation to API
tickets response body I.D. I'm gonna set the exact same cookie on their and I'll send along our actual
update to make about this time we give it a legible title I'll say new title and a price of one hundred
coming out of that I'm going to expect to get a two hundred
and then finally we could be happy at the two hundred.
Or alternatively we could do one more follow up request to try to now fetch this ticket and write out
an assertion and say this thing was actually updated we did not do that on the earlier test.
Up here we were making sure that update did not occur if the user was not logged in.
So since we did not do it not there let's do it down here just we can see what that would really look
like.
So I want to make a follow up request and just say OK on fetching this ticket after it's been updated
it actually has the new title and the new price to fetch that ticket.
We will make another request here and going to save the response as a variable.
I would call ticket response we'll do our request to app.
I want to make a get request and I want to fetch a very particular ticket so I gonna make a get request
to a very slow your El API tickets and then the idea that ticket.
So API tickets response body I.D. I'll send that off.
We do not actually have to set any cookies or anything like that because we do not require authentication
to fetch details about a single ticket down inside of here let's write out our expectation.
So we're going to expect the response body right here inside there we should see details about that
ticket in particular we should have the title and a price the title should be equal to needed new title
and the price should be equal to hundred.
So we will expect ticket response body title to equal
new title.
I'm going to do a little copy paste.
I'll check the price and make sure that is equal to 100 All right.
Let's save this and just make sure that this test is failing.
So I just wanna make sure that it's not erroneously passing for some reason it's back in my terminal.
Yep looks like we're good to go.
The update was received but never actually applied so let's go and now do a little bit of update to
our root handler itself.
I'm gonna go back over to the root handler handling updates right here then we're gonna go right after
we do the check to see if this user actually owns the ticket and if they do own it we're going to apply
the update to apply the update we can use the set commands on the ticket document that we already fetch
whenever we call set we can pass in an object that contains the properties we want to update this thing
to so we want to change the title to wreck dot body dot titled and price to wreck body writes
After setting some new properties on the ticket that just makes updates to the document in memory it
does actually persist those updates back to our Mongo DB database after calling set we then have to
do and a weight ticket dot save and that's what's going to actually persist everything back it just
you know a little bit of trivia after we call save those updates will be persisted to the database and
mongoose is gonna make sure that any further updates either due to some post save hooks pre save hooks
something done by Mongo DB itself or whatever else all other possible updates will be persisted back
to this ticket document that we already have a reference to.
So we do not have to say refresh this ticket to get the updated version that's been saved.
We already have the updated version right here so we can continue to rely upon results sent to send
back details about this updated ticket.
Let's say this take a look at our test see how we're doing so looks like we're green across the board.
Fantastic.
This is a super long video.
So let's take a pause right now and do a quick wrap up of all these different root handlers in just
a moment.