I would really like to write out one or more two quick tests around our sign up Route handler at this
point we've really only been making sure that the responses that come back are of an appropriate status
code.
So in this case we're gonna take a look at a slightly more in depth test just slightly so in the side
of our route handler as a quick reminder we take a look at the email we make sure the email is not in
use.
We then create and save a user.
We then generate our Jason web token and then we store it on that session object.
Remember that such an object is going to be turned into a string by Cookie session.
A cookie session Middleware is then going to attempt to send this cookie back over to the user's browser
inside the response to be really precise on what happens there in order to send that information back.
It cookie session Middleware is going to set a header on the response.
This header has a name of set dash cookie so to make sure that we actually generate a J somewhere token
and send it back and said that response.
Let's make sure that after signing up successfully a response has a header of set dash cookie we could
always also try to inspect that cookie and make sure as adjacent a token.
Well let's start small right now.
Let's just make sure that the response has that header.
OK.
So to write out this test I'm gonna go back or add my test file.
I'm gonna put together another block at the very bottom and I'll say something like it sets a cookie
after successful sign up
then inside of here we're going to make another successful sign up request rather than writing out from
scratch I'll just copy paste the one we did in the last test.
Make sure you copy paste the one that has a status code of 2 a 1 not the 400 I'll paste I didn't like
some so now after making this request we need to somehow inspect the response that comes back from it.
It turns out that when we make a request for a super test this entire recall right here returns the
response so we can say response like so and that right there is our response object the same kind of
response object that we get access to inside of our request handlers like that one right there so we
can take a look at that response and try to inspect the data that we're trying to send back inside of
it or also inspect the headers.
Of course we care about the headers in this case so we're gonna write out expect response dot get so
get right here is a method that is built into the response that allows us to look up any of the headers
that have been set in the response the header that we were going to try to look up is set dash cookie
like so make sure use the capital letters as I did so we're going to attempt to pull out that cookie
and then we will expect that it is defined so we'll write out not to be defined like so OK so let's
say this and run this test.
Now I want you to know right away.
This test is going to fail.
But nonetheless let's run it anyways if I flip back over.
Yep I see as matter of fact we got a value of undefined when we try to get that set cookie header which
means that there is no set cookie header inside the response so it looks like our test is failing entirely
even though we know for a fact that we've been able to sign up using this request handler.
So what's going on right now.
Well this is a very very small technical issue and this is why I really want to highlight it specifically
in a test around checking to see if that cookie exists as a reminder back inside of our app dot TSA
file which is where we create our Express app and wire up a bunch of middleware when we wired up that
cookie session library.
We said secure true right there secure true means that cookies are only going to be shared when someone
is making a request to our server over an HTC CPS connection when we make use of Super Test.
We are not making an H2 G.P.S. connection.
We are making plain HDP requests.
Cookie session sees that and says oh I don't care that I'm in a test environment I'm only sending cookies
if this is a secure request.
In this case it's not we're not making a secure request in the test environment so we could either figure
out how to make a secure request or alternatively what would be way easier to do and way more time effective
we can decide to change this secure property to False if we are in a test environment.
So if we are running our test through just we're going to flip the value of this thing to false and
that will allow cookie session to set that cookie even if the request is not secure to do so we'll take
a look at another environment variable we're gonna put in here a process in be node underscore EMV not
equal to test so whenever just runs our tests at the terminal that's going to set this node environment
variable equal to the string test.
So we're saying that if equals is equal to tests give us false otherwise if we're in any other kind
of environment be at development or production then set secure to true let's say this now look back
over our terminal and now we're gonna see that test pass awesome so again I really just want to highlight
the fact that we needed to add in this little change right here to get all of our authentication stuff
working in the test environment all right now as I mentioned there are a ton of different tests we could
run right out around our sign up request handler but I think that what we've put together so far is
pretty much good for right now.
I don't want to totally overdo this testing stuff.
In addition I would like to write out some tests for our other request handlers as well.
So let's take a quick pause right here.
We're gonna start to write out some request handlers for all these other seeing some test for these
other request handlers.
Muslims are going to be pretty similar in nature but there will be one or two locations where we run
into some other interesting issues.
So let's start to write out these tests in just a moment.