The test we have put together that relies upon mocking the stripe client definitely works.
However I thought would be fun to take a look at an alternative way of putting this test together.
And in this alternate way we're going to allow in the test environment our root handler to talk directly
to the real stripe API.
And so this will ensure that we are really creating a charge with all the correct values and that stripe
has actually successfully gradient for us.
Now this really is optional.
I'm really just going to show you this alternative approach and it's really up to you which approach
you want to use.
Although I will say it is kind of an either or you're going to either use this mock approach or you're
going to use this more realistic way that I'm about to show you the downside to the realistic approach
is that these tests are going to take a little bit longer to run because we do have to make a request
to the real stripe API OK so enough of that.
Let's take a look at how you put this together.
The person you'd want to do is make sure that we remove our stripe Mark.
We don't want to mark out that client anymore.
We want to use the real stripe API so to remove that at the very top of our test file.
I will remove the just mock statement and then inside of my MOX directory I'm going to rename that striped
T S file to striped T S dot old to the dot.
Hold on there just just changes the extension just so we do not accidentally load up that file OK.
Next up we need to make sure that our local test copy or the in a test instance of the stripe client
we create has access to our stripe API key remember that we did set up a Cuban net a secret to store
our key but that secret is only accessible inside of our Cuban cities cluster and our tests are running
outside of the cluster.
So in our tests are running we do not have access to the key.
Now ideally we would store this key inside of an environment variable on your local machine.
However setting up environment variables is very different depending upon your operating system and
even what Shell you use.
So ideally you would set this up as an environment variable but I will leave that as an exercise to
you and instead you and I are just going to cheat we're going to directly set the environment or the
stripe API key inside of our test setup dot t s file very similar to how we set some other environment
variables inside of here right above the before all statement I'm going to define stripe key and then
I'm going to assign my api key to that variable so as a reminder you can get that from the stripe dashboard
by going to developers and then api keys and you'll see these secret key right there.
That's the one that we want to use paste that in like so those that we are not placing that environment
variable next to all the others.
The reason for that is that we have to define this API key as soon as possible because it's going to
be used the instant that we first require in the striped T S file inside of our s our C directory gang
and to say that file and then close it.
So now whenever we run our test suite and we run that test right here though our success case tests
when we make our request that's going to reach out to the real stripe API.
We are still making some expectations right here however that is assuming that we are working with a
mock function trying to delete all those expectations and we now need to figure out some other way to
reach out to the stripe API and make sure that we actually are creating a charge with all the correct
attributes because again that is the whole goal of this test.
We want to make sure that a charge was created and that is can you just a little bit challenging.
So let me show you a diagram just to summarize what we have to do and help you understand why it is
kind of a challenging process.
OK.
So in this diagram we've got our test file.
We've got a root handler in the stripe API so inside of our test file we are going to more or less make
a request to Overton throughout.
Handler will include a token and some order I.D. that root handler is going to run and then it's simply
in time it's going to reach out to the real stripe API.
It'll provide some token some amount some currency for a charge to be created then the stripe API is
going to immediately return some details about the charge that was just made that these details about
the charge was just created.
That is what we would love to get access to inside of our test file because then we could write out
some expectations and make sure that the charge was created that was created as the correct amount as
the correct.
Who knows what else be the correct date or something like that.
In other words we would really like to get information about this charge into our test file so we could
write out some expectations but right now our root handler does not return any information about the
charge that was created that does not happen right now.
Of course we could very easily change that.
Without a doubt back inside of our root handler so here's new to us here's a recreate the charge.
We could definitely take some information about the charge that was made and then send it back to ever
made this request and then inside of a request to or is it gives me inside of our test file.
We can receive that information and make sure that the charge was made has some correct attributes.
But if we did that we would be changing the implementation of our code just to better suit our test.
And that is usually a really bad sign.
We usually do not want to make any changes to our code just to make it easy user to write out some very
particular test rather than trying to take this information about the charge that was created and fought
it back over the test file.
We are gonna figure out a different way to do this we're gonna figure out a different way to make sure
that our test file can get some details and make sure that the charge was created has the correct properties.
So how are we gonna do that.
Well let's take another look at the stripe API back at the stripe API documentation.
Again this is at docs API charges weird took to took a look at the created charge and points.
There's another endpoint to retrieve a charge.
So this will get information about a charge that has been created but we have to provide the idea of
the charge.
Once again we currently are not really able to communicate any information about the charge itself from
the root handler to the test file and it's unlikely that we will ever change that so unfortunately this
retrieve a charge and point is not very helpful.
But there is another one that we might be able to use if we get just a little bit clever.
There is an end point of list all charges by default.
This will give us the previous 10 charges that have been created and we could increase that up to 100
if we wanted to.
So here's my idea.
We're gonna have our test file make this request the root handler will send that off to stripe.
We'll get the response from stripe back and eventually the root handler will send back a message of
success true to our test file.
After we get that success back we're then going to have our test itself reach out to the stripe API.
We're going to request a list of the 10 most recent charges that have been created.
We'll say give me a list of the 10 most recent charges the stripe API is going to respond with that
list of 10 charges so list of 10 most recent and then inside of our test file.
We're going to take a look at those 10 most recent charges.
We're going to make sure that there was one charge that has the what looks like the correct set of properties.
So perhaps it has maybe some correct token some concurrency or something like that.
Now this would definitely work.
But remember that token and the currency are always gonna be the same for every single test run.
So we could potentially be taking a look at some data inside this list of 10 most recent charges that
is stale or belongs to some tests we ran say some minutes ago.
So we need to make sure that whenever we create this charge there's some unique identifying information
inside of it that we can use to identify that charge inside this list of 10 most recent charges inside
of our test file so we can get some unique information inside there.
Well we're going to use that currency remember that inside of a test file.
We are creating the order that we are trying to purchase right now.
The order is hardcoded to be 20 U.S. dollars so instead of using a hardcoded value of twenty dollars
we're going to instead randomly generate a price for the order instead we will randomly generate a price
assign it to the order and then when that root handler makes the request to purchase or create the charge
we will see that randomly generated amount inside there.
So we'll be like some amount like that.
Then when we get back our list of 10 most recent charges we can try to find a charge with that amount
to some amount of 9 to 2.
Blah blah blah.
And if we find a charge in the list of charges with that amount that means that we must have successfully
created the charge inside the root handler.
And at no point time will we have had to change any code or return change the return value of drought
handler just to better suit our test OK.
So I know this entire setup is kind of complicated but again I just want to show you this alternate
approach.
Let's take a pause right here and implement this in the next video.