We've now put together our very first test right here which is fantastic.
We're gonna start to write out a couple of more tests around that sign up.
Root handler.
Now the nice thing about using super test is it's really easy to write out a test.
So we're gonna put together a fair number.
I just wanted to give you a good example of all the different ways in which we could test a very basic
root handler.
So let's get to it.
The next test I want to put together is just make sure that if we put in some kind of request or try
to sign up would say an invalid email or password the requests should fail and we certainly could write
out a test to say hey let's make sure that we fail the request and send back some very appropriate error
message where we're gonna take an even more basic approach in that we're gonna say that if we send in
some invalid email or password let's just expect that we get a response that has a status code of four
hundred which would indicate that we failed to sign it we absolutely can try to write out an assertion
to make sure we get the appropriate error message but again we'll just keep it really quick really simple
and make sure we get back a status go to 400 to back inside my test file Aladdin in its statement and
say it returns a four hundred with an invalid email
rather than writing out the entire request again.
Let's just do a quick copy paste.
So I'm going to copy that block right there.
But into the second one and now all we have to do is update the email to be something invalid and change
the status code.
So I will put in an invalid e-mail and I will expect to get back a status code of 400 so going to say
that go back to where my terminal and there we go.
You'll notice that I'm getting a console log right here.
That's just because we still have a leftover console log inside of our era handle middleware.
Remember our air handler middleware anytime it sees an error is going to do a log of the air that's
coming across.
We probably don't really want to see this in that test environment.
So let's just go delete that console log from that area handler.
I'm going to go and find my middleware directory.
I'll find the air handler inside there and I'll just delete that console log.
Pretty sure we just had that in there for testing purposes or manual testing purposes.
I suppose a little bit ago Jeff I flipped back over.
Awesome.
We have to test passing anything on to mention.
I meant to mention that earlier when we first started up our test suite the very first time you start
up the test suite that's going to take about eight or all the way up to 20 seconds to start up.
And that's because that in memory copy of Mongo Debbie just takes a little bit to load but after it
has been loaded we no longer have to restart Mongo DB.
For each individual test run.
So after that long initial startup all of our tests are going to run very very quickly I can hit enter
while at the terminal to rerun my tests and as you can see these two tests run very very fast.
All right let's add in a couple more.
Very quickly I'm going to just do another copy paste of this entire block right here there's the paste.
I'll say it returns a 400 with an invalid password so an invalid password as you'll recall is any that
has a length less than four or greater than 20.
Let's just try putting a password with one character.
I'll put in a password appear right there.
If we have an invalid password we should get a 400 so we'll save this.
Go back over awesome.
Got another passing test.
Let's try.
Just doing one more will do.
We'll try saying that if we send in a request that does not have an email or a password.
We should get a 400 as well so I'll do another copy paste that it block and I'll change the description
to it returns a 400
with missing email and password
and then I'll just send in an empty object like so.
Now of course we could write out two separate tests one to just have the email missing one at the pass
from missing absolute feel free to do so if you want to in fact I'll just show you how to do that.
If you want to write out to submit requests inside of one handler that's when we'll start to use that
async await syntax so you'll copy that block right there a step right above the return and then on the
first request we have to add in and wait.
So we will await this request to be completed and then we will return the next one.
Behind the scenes just is going to automatically await this request for us so we technically don't even
need the return there.
We could instead use a wait and see.
Same thing is true of everything up here.
We just need to make sure we either return requests or await it.
Either one is fine now maybe and the first one we could put in a valid email
and in the second one we could put in a valid password
on and say this flip back over
all right so you can see it is pretty darn easy to write tests with Super Test but well right now we
are really just making expectations around the response 70 some more complex behaviors going on inside
of here.
So let's take a quick pause.
We'll start to test them the actual infrastructure of this thing in just a moment.