In this lesson you'll be kicking off our section on node j s testing by doing two very important things.
First up you'll be creating and running your very first test so you'll see exactly what tools we'll
be using to get that done.
Then the second thing you're going to do is take a few minutes to explore why testing code is so essential
whether it's a no J Yes application or an application written in another programming language.
You should be writing test cases to automatically verify that your project is always working as expected.
Now that order might seem a bit counterintuitive.
You might want to know why you should test your code before you actually write your first test.
But I promise it's gonna be a lot easier to understand why you should test code after having already
written a test case.
So that's the order we're going to take.
We'll write a test case then we'll talk about why tests are so important.
And by the end you'll be ready to continue on and start to write tests for the task manager app.
All right let's go ahead and dive right in.
By setting up the one tool we're going to need to write our test cases.
Now there are literally dozens of different libraries that allow you to create and run tests for your
notes.
J asked application over in the browser.
We're going to explore two of the major players one of which we'll be using in this section.
So let's crack open two tabs.
The first tab is going to open up the just testing framework which we can find at just j s dot I O.
Now this is the testing framework we're actually going to use in this section.
The other testing framework which I want to take a quick moment to address is Moka.
You can find that over at mocha J S dot org.
Out of all of the options available to you as someone who wants to write test cases for their note J
asked project I'd say that Moka and jest are definitely the most popular and the most widely used.
Now as you head out into the real world and start to work on Node projects whether they're open source
or for a company you'll see some companies that happily use Moka.
Other companies that happily use Gest and other companies still that use other testing frameworks entirely.
All of these can achieve all of these same results.
So in the end of the day it's really just a matter of picking one that fits your personal style and
preference and then starting the process of writing your tests.
And the good news is that it's pretty easy to switch between them should you need to.
But once again they can all do the same stuff.
So what we're going to do is go with jest just as a bit more modern and comes with a couple of nice
to have features that just make it a little easier to write and manage our test cases.
So what I'd like to take the next few minutes to do is set up just in our task manager project and create
and run our very first just test over in Visual Studio code the very first thing we need to do is install
a brand new NPM module so something new as a development dependency to all of the modules for testing
our application are only going to run on our local development machine.
They're not things we're going to need on our production server so we can install them as Dev dependencies
right here from the task manager directory.
We're going to install just using the following command that is NPM I jest at twenty three point six
point zero.
Then we'll specify that save Dev flag to save jest as a development dependency.
I'm going to take a quick moment to run that and once it is done all we need to do is setup a single
new script that script is going to start up just and just is a zero configuration testing framework.
That means that by default it has everything in place for us to get started.
But of course there are options and arguments we can use to customize it as we want to change how just
works and we'll explore some of those a bit later but for now Gest is installed and well we're going
to do is create a new script in our scripts object.
This script is going to be a key value pair like our other ones.
The name of the script will be test and what are we going to do.
We're gonna use gest that is just and we're done.
There is no need to provide any additional details.
So right here when we install jest we get access to it as a command we can execute.
We could install just globally to run it from the terminal but since we've installed it in our project
like we've did with things like node man we can simply access it from our drifts up above.
Now that we have this in place what I want to do is actually run the test command just to see what we
get.
So from the terminal I'll be using clear to clear the terminal output.
Then I'll go ahead and run NPM test.
I'm gonna fire off the command it is going to start up just and what do we get.
Right here we can see we have an error the error message.
No tests found it's telling us that it's looked in our project.
The task manager directory and it's checked 10 files for test cases but it hasn't been able to find
any test files.
So what we're going to do is create our very first file to house our very first test.
The first thing we want to do is create a new folder for all of our test cases.
So that's gonna be a new directory in the root of our project.
So a new folder in the task manager directory which I will call tests.
Now that name is not particularly important.
You could call it whatever you like but the name it tests is pretty clear.
Next up we'll be creating a file to contain some test cases as we write more tests.
We will break them up across multiple files.
But for the moment we can just start with a single one.
Now right here let's say we're trying to write some tests to make sure some math functions we've created
are working as expected I might call the file something like math dot test dot J S in here we'll write
our test cases and this file will be picked up by jest.
The reason Gest is going to treat this file as a file that contains a test cases has to do with the
name of the file itself.
So it ends in dot J.S. meaning it is a file that contains javascript code and that's true all of the
code we write in here is gonna be plain old JavaScript.
The dot test extension that makes sure that gest knows this file contains and test cases that we want
to run so down below it saying that it checked 10 files but wasn't able to find any test cases because
none of the files in our project had that dot test dot J asked extension.
Now that we do have a file that has this extension let's go ahead and run NPM test one more time.
Now it's still not gonna work.
But it's going to fail for a different reason right here.
We'll use clear to clear the terminal and NPM test to rerun just one more time.
Right here we can see that it has indeed failed.
And if we scroll up we will see why.
So right here it did detect our file math dot test dot J S in the test directory.
Right here we're getting the following message test suite failed to run and it says that our test suite
must contain at least one test.
So right now just as saying that our test cases have failed because we have a file but it doesn't have
any tests.
So let's go ahead and fix that by actually creating our very first test case to create your first test
case.
All you have to do is call the test function.
Now you'll notice that the test function is not being loaded in with anything like a require just actually
provides the test function as a global in your test suite files.
Now just provides other Global's as well.
And we'll explore those as we continue through the section for now.
All you need to know is that in your test suite you call test to set up a new test.
Now right here when we call it we provide it two arguments.
The first is a string and the second is a function.
The string is the name for your test case.
So I could say something like user should not be able to sign up with a password shorter than X characters
for the moment though we'll go ahead and say something like hello world.
Perfect.
So now we have our test case name in place.
And here we have the function.
The function contains the code you want to run to actually verify that the given feature is working
as expected.
Now for the moment we're going to leave that function completely empty and simply save the file with
this change in place.
Down below from the terminal.
Once again I'll be clearing the terminal output and using NPM test to rerun that test suite.
And right here we can see it is looking through math dot test dot J.
S and right here our test suite is now passing.
I have a little checkmark next to my test case.
Hello world with some statistics down below.
So right here we have a passing test suite even though this function does absolutely no thing now this
test case isn't doing anything but it is considered a passing test case.
So why is that.
When we register a test we call the test function providing a name and the function when Jesse runs
our tests.
It simply runs that function.
If the function throws an error then the test case is considered a failure.
If the function does not throw an error then the test case is considered a success.
So down below.
Let's go ahead and call test a second time to set up a second test case for the name I'll pick something
like this should fail.
Then I'll go ahead and provide that second argument.
The function to run and to actually make this test case fail over going to do is throw a new error with
the following message failure.
Perfect right here.
We're going to save the test suite down below I'll use clear to clear the terminal output and NPM test
to run that test suite again.
Right here I would expect just to find my file run both tests and down below we can see that is exactly
what's happening.
So right here we have our general summary test suites.
We have 1 total test suite and it has indeed failed.
And down below individual test cases I have two total tests one passed and one failed.
Now if I scroll up I can get some more information about the one that did fail.
Right here I can see which ones succeeded and which ones failed.
I have the error message that was provided and I can also see exactly where that occurred in the test
case.
So there we go when we're creating tests over doing is creating functions.
If everything worked as expected we don't throw an error.
If something went wrong we do throw an error.
Now we could use this approach to test a simple function that adds up to numbers.
We can also use this approach to try to log in to our Express API with invalid credentials making sure
that we don't get an off token back.
So this simple principle is going to be able to be expanded into more complex real world scenarios.
So down below let's take a quick moment to talk about why we want to write test cases for our projects
right here.
I have a few key points though there are others so why test.
First up testing saves time.
Now yes you have to write more code but that's OK.
We write code wants to test a specific feature and we can run it as many times as we'd like.
So if I create a new feature I create a test case for it.
Then over the next four or five years of development I can keep just running that test case automatically
by running the test command.
There's no need to recreate it or do any manual work whatsoever.
Now this is gonna be even greater as your application grows in size.
It will no longer be feasible to manually test everything and you'll rely on an automatic test suite.
Which brings us to the second point.
When we test our code we create more reliable software.
So whether you're just creating a project for yourself or working with a company or trying to launch
a startup writing test cases is going to make it much easier to create reliable code.
You'll be able to spot and fix bugs before they actually get shipped to production and mess up users.
So we will have a test suite that makes sure everything is working and if something in our application
was to break one of our test cases would fail alerting us that something's wrong.
If we run the test suite and all of our test cases are passing then we know everything is working as
expected and we could have a little more peace of mind that our software is functional.
Now when we have a test suite in place it also gives flexibility to developers.
I can refactor code trying to do things in a different or faster way.
And as long as my test cases are passing I know I haven't broken anything I've just changed how something
is done.
It also makes it much easier when collaborating with others.
If someone's coming into your project to add a feature or fix something they might not be up to speed
on all of the different features of the software and how they fit together.
When you have an automatic test suite that new developer can simply run the test cases and ensure that
they haven't broken anything when they changed one area of the project.
You can also do a bit of profiling so you can see if these speed your test cases run goes up or down
as you make changes so you can slowly make your application faster and faster over time.
And lastly a point I already mentioned is peace of mind.
You'll know that you have an automatic test suite.
You can run to verify your entire project in a matter of seconds.
If I wanted to make sure the task manager was completely functional I would have to go over to post
man.
I'd have to fire off a bunch of different requests changing things to make sure I got the correct errors
when bad data was provided.
It wouldn't be a slow process and there would be a lot of room for human error.
It's possible that I would see the results and not realize they're incorrect when we have a code based
test case.
We can rerun our entire test suite by typing out six characters and waiting a few seconds.
That's powerful and it's going to allow us to create better software over time.
So I am really excited to dive into testing because it is such an important feature in the next lesson.
We're going to create some test cases for a few example functions.
I'm excited to get to that.
So let's jump right in.