We were able to create a charge with stripes successfully and now we should probably write out some
kind of automated test before we write out the test however I want to mention that there are two different
approaches we can use to really test out this type stuff.
First we could test this out by trying to make use of the actual stripe library.
We can make sure that whenever we run a test or tried to test this handler we could ensure that we reach
out to the stripe API successfully and create a new charge.
And that would definitely be a very realistic test.
However it would also be kind of annoying to put together because remember that environment variable
for our stripe key is only accessible inside of our Cuban I.D. cluster but we are currently running
our tests on our local machine outside of the cluster.
That means we do not have access to that environment variable.
So if we wanted to somehow make sure that we could reach out to the real stripe API we'd have to make
sure that as we run our tests we still have access to that API key.
That would involve just a little bit of setup possibly of creating a new environment variable on our
local machine.
It would definitely be something we could do but again just a little bit annoying.
The second approach we could take is to create another muck around the stripe library itself or really
our striped T S file.
You might recall the inside of our SRT directory.
We've got the MOX folder.
We've already got a mocked Nats wrapper.
We can create a very similar mock or the stripe t s file as well and we can make sure that we export
some kind of mock object that has the same kind of API as this thing right here.
So some kind of object that has a charges property and on that charge is property has a create function
that returns some kind of promise that will eventually be result again.
Two possible approaches we're gonna first take a look at how to implement this using a mock and then
maybe we'll see what happens.
Perhaps we'll refactor it to use the actual stripe API All right.
So to get started inside of our MOX directory inside the s RC folder we're gonna make a new file of
Stripe dot t s it's inside of here.
We're going to make a fake copy of Stripe and this will be executed or imported only when we are running
our code in the test environment.
So ultimately we want to export something that is going to have the same kind of structure as this file
right here.
So we want to make sure we export something called stripe but the lowercase S. and it needs to have
a charges property and on the charges property it has to have that create function so inside of this
mock file I will export bounced stripe.
This is gonna be an object that has a charge is property and on charges we will have a create function
for this great function right here.
Well we could definitely make it a real function but instead we're going to make it a just mock member
mock functions are really fantastic because we can take a look at them make sure they get called with
appropriate arguments we're gonna put in here just f n and this time around this mock function is gonna
be just a little bit more complicated.
You might recall back inside of our Nats wrapper or the mock function we created over here.
We changed on that mock implementation function and that made sure that time we called the public function
we actually executed this function right here.
We're gonna do something very similar this time around but instead of providing a mock implementation
we're going to instead provide a dot mock resolved value
to this mock result value right here.
Make sure that whenever we call the create function that we are going to get back a promise that automatically
resolves itself with an empty object.
The only reason we are doing this is because back inside of our actual root handler our expectation
right here is that when we call create we are going to get back some kind of promise and then we are
awaiting that promise to be result so that's why we are going to mock resolve value.
We're gonna return a promise immediately that automatically resolves itself okay.
So that is it for the mock file believe it or not.
So now we can go back over to our test file inside that test directory and we could write out a new
test that asserts so we can make a request to our endpoints with some valid token or whatever else.
We'll make sure that we call that Mark create function then we could write up some kind of expectation
around it.
At the very top of this file we will tell just to redirect the import to that stripe test file and instead
use our mocked version of these strike teams file we'll do a just dot mock up to directories stripe
then down at the bottom of file
we'll put together a new test and say it returns a about to a fourth because we are technically creating
a record year with valid inputs inside of this test.
We're going to do a little bit of setup called a handler and then maybe also make sure besides the fact
that returns a two a four.
Make sure it actually calls that create function or the charge create function and provide some valid
arguments to it.
So inside of here we're going to do the same kind of setup we did in the previous test.
I to go to the previous test and just take everything from user I.D. down to the order dot save it's
going to copy all that and put it into our new test I will update the status here from canceled to created
to make sure that we can actually pay for this order and then after saving the order I'll make the actual
request so I'll do it in a wait.
Request due at I want to do a post request to API payments I'm going to set my cookie to user or a global
dot sign it.
That's why I want user I.D. and I'm going to send along
a valid token.
Now keep in mind that this token is not actually going to be used because we have mocked out the charge
create function but we will remove that mark and just a little bit to take a look at an alternative
approach.
As I mentioned and so eventually we do want make sure they've got a valid token here.
So since our account is in the test mode we can put in T okay underscore visa and as I mentioned this
is a token that is always going to work for strip accounts that are in the test mode and then our order
I.D. will be the I.D. the order we just created a moment ago to order dot IP all right this video is
running a little bit long.
So let's just take a quick pause right here and then wrap up this test in the next video.