Let's put together a couple of quick tests to make sure that we handle these three different cases appropriately
so inside of my roots directory I'm going to make a new folder of underscore underscore test underscore
underscore and an inside that I'll make a new file of new tests.
Yes.
It has been a while since we tested out a root handler but remember it's a lot easier to test about
handler than a listener or a publisher.
All we really have to do is make use of the request or the Super Test library.
We're also going to make sure that we get our Express app.
We're going to make a request to express app and that's pretty much it.
So at the very top we'll import request from super test and we'll also get our Express app from up to
directories
so we can start to write out a couple of different test cases.
Maybe the first test case we should write out is make sure that we throw an error if we tried to purchase
an order that does not exist so I'll put in a description here of it returns a for a for when purchasing
an order that does not exist
let's write out the other test cases as well.
So we should also handle something where we are trying to pay for the order as a different user and
something around making sure that we cannot order or paper in order after it's been canceled so it's
returns a 4 or 1 when purchasing an order that doesn't belong to the user
and it returns a 400 when purchasing a canceled order.
So now we can write out some actual implementation for each of these naturally we will start off with
the 4 0 4 first instead of here.
I'll put in an a wait we'll make a request to app I want to make a post request to API flash payments
I do need to set a cookie on this thing using that global sine function because we are requiring a user
to be authenticated to make a request to this handler.
So we do have to call the set cookie to global dot sign in and we're going to send along some imaginary
token for right now and an order I.D. for well nothing and this order I.D. might end up throwing some
kind of error when we make a query with it we might get some kind of air from mongo saying hey sorry
but this thing is not an actual Mongoose I.D. or Mongo DB I.D. So rather than throwing in a gibberish
maggot or idea right there order I.D. let's generate a real looking I.D. using Mongoose once again the
very top I will import Mongoose from Mongoose and then for the order I.D. we'll throw in Mongoose dot
types object I.D. to X string
and then after we send that request off we will expect to get back a four for and that should be at
let's say this right away and make sure that this test succeeds back inside my terminal I still have
all my tests running it looks like that test just passed as usual let's try to make it actually fail
I want to send along or I'll go back over to my root handler and I'm going to remove that check to make
sure that we actually have an order you'll notice that the other checks right here start to fail as
well.
It's all to combat those out temporarily.
So now our test should fail saying that we get back a status code of 200 instead of the expected for
a four and that is exactly what we get.
I feel like the tests we just wrote is probably working as expected.
All right so let's take care of the other two cases.
So next up is the for one when purchasing an order.
When this thing does not belong to us you might think they were going to have to create two users to
test this out or something like that.
We really don't.
We really just have to create one order save into the database with a realistic looking at user I.D.
and then just make a request and try to pay for that order as any arbitrary user.
And we'll we will make sure that we get back it for one.
So first things first we do have to create a real order and save it to the database.
For that we have to make use of our order model.
Let's import it at the very top going to imports order from up to directories models order then downside
of our test.
We'll do a on order is a wait or see me order not Bill.
There we go no await statement just yet and we do have to get this thing a couple of different properties
unfortunately.
So we have to give it the I.D. version user I.D. price and status with the I.D. We do want this thing
to look realistic.
So we'll throw in a mongoose types object I.D. to hex string
for the user I.D..
Well this can be any idea whatsoever.
But let's make it look realistic.
Just for tests sake.
Again not important.
We can't have the thing be gibberish if we wanted to but I'll just make it look like a real I.D. I got
a hard coded version to be zero I will hard to code the price to 20 and then finally our status to set
this we do need to import our order status in them.
We'll make sure I do that at the top.
From our common module
then we can set the status right here as order status dot created after we create the order will then
save it within a waits order not save.
And now we can actually make our request and try to pay for this thing rather than writing out the entire
request chain once again.
I'll just copy paste some code from the previous test.
It's going to take all that stuff right there.
Copy it and then paste it in.
So now instead of giving a randomly generated order idea right here I'm going to instead use the idea
of the order that we have just saved to the database.
I'll specify order dot I.D. and I will expect this to give us back if we're a 1 would save that.
Take a look at our test Yep what's good as usual.
Let's just try to make this thing fail.
So how about rather than going and commenting outside those checks we'll try to expect a different status
code.
We'll expect about a 200 and that's to just confirm that we do in fact get back a 4 0 1.
Yep looks good.
Let's take a pause right here.
When we come back the next video we will take care of this last test.