In this lesson we're going to continue to explore new testing techniques and the goal here is to figure
out how we can mock our NPM modules so the process of marking is the process of replacing the real functions
that run with functions that you create when we're running in a test environment.
Now why might that be something we ever want to do.
Well let's think about what all of this code actually does.
We run various endpoints like the one for signing up and the one for deleting accounts.
And we know that when both of these execute emails are sent behind the scenes emails are sent to email
addresses that don't exist and will never be checked.
And that alone might not be the worst thing.
The problem though is that we're constantly rerunning our test cases which means we're just racking
up unnecessary emails being sent from our set grid account.
Now if we're on the free plan that means we don't have many free emails to send.
And if we're on a paid plan and that means we're wasting money on emails that will never be opened with
mocking we can make sure that when our program is running using just we don't actually send those emails
off.
Well let's get started by creating the directory where we can store our marks.
So right inside of the test folder if we're trying to mock and NPM module what do we do we create a
MOX directory.
Now it starts with two underscores that's two there and not just one.
Then we type out MOX in lower case than it's two more underscores this is the directory name that just
is going to look for now in here we can create files for the individual modules we're trying to mock.
So if I wanted to mock something like Jason Webb token I would create Jason Webb.
Token dot J S in the MOX directory in this case we're trying to mark the module used right here that
is at seven grid forward slash male.
Now right here they are using at followed by the organization then forward slash the individual utility.
This is known as NPM scope and all that means for us is that we're going to create a directory with
this name inside of MOX.
Then in that folder it will create a file with this name and the J.S. extension that will allow us to
mark out the functionality providing our own versions of set API key and send to use when running in
test mode.
So right here let's get that done in the MOX folder will create a new folder at send a grid and in the
send grid directory it will create a new file this one mail dot J S.
Now it's important that when we're marking out a module we provide all of the things that that module
needs in order to work.
So our application code is expecting things like set API key and send to actually exist.
So if we're going to mark that module out we need to provide our own versions of all of this.
So the code at least doesn't fail.
So right here that means we need to export an object with those properties on it because that's exactly
what set grid is doing.
We get an object back with those properties sitting right on it.
So over here will actually kick things off by using module exports and setting it equal to a new empty
object.
And on here we'll provide a set API key and send no down below you'll actually notice that our test
suite is failing and if we scroll up we can see why right here test suite failed to run.
And that's referring to our user test suite.
And the reason is that s g mail dot set API key is not a function.
And they're right now the reason this is happening is because we've provided a mark for that module
but we're not exporting an object with that function defined.
So let's fix it right here on this object.
I'm going to set a value for set API key.
I'll go ahead and set it equal to a new function and I'll do the same thing down below for the other
method we're using sent.
Now if we were using even other methods from the module we would want to mark those as well.
Now when it comes to mocking you could choose to accept arguments and then return some sort of fixed
value.
In this case in account dot J S we pass in arguments like the email to be sent or the API key to be
set.
But we don't do anything with the return value.
So there's actually no need to do anything inside of these functions.
All this is gonna do is allow these functions to be called over here but in reality nothing is happening
behind the scenes and that's good in the test environment.
No api keys will be set and no emails will get sent now if I go ahead and save male dot J S we'll see
that our test suite does restart and this time it should be brought back to its working state.
And it is.
Now if you want to learn more about MOX as always it's defined in the documentation like everything
else we have explored related to just under guides in the sidebar.
There's a page called the manual marks which covers everything we just talked about right here a mocking
note modules outlines what we just did.
So that's where we're going to stop for this one.
I wanted to introduce the concept of marking allowing us to not send those e-mails from our test environment
though we won't be using them for anything else in this test suite.
The nice thing now though is that as our test suite reruns we're not going to be wasting our limited
emails that we can send off.
All right.
That's where we're going to stop for this one.
I'm excited to continue on.
So I'll see you in the next lesson.