All right my friends.
I think we now have a plan.
So when we create the order inside of our Test File we're going to randomly generate a amount or the
price for the order.
Then when that goes off to the stripe API it should have some amount but that very specific amount.
Well then later on INSIDE THE TEST file it request a list of the 10 most recent charges we should be
able to then iterate through that list of 10 charges and find a charge with that same randomly generated
amount.
Now the one thing to keep in mind here something that's going to make our lives just slightly slightly
difficult.
Remember that inside the order we are providing a price that is in units of dollars or for the charge
that gets sent off to the stripe API.
It's gonna be in units of sense.
So we are going to generate a price.
And then when we try to find it inside of our list of charges that we just have to remember to multiply
that price by hundred to go from dollars over two cents.
OK.
So let's get to it inside of my test right above the order.
I'm going to randomly generate a price so I will do a math dot random times hundred thousand and I'm
going to wrap that with a math dot for or then provide the price as the price property for the order
itself.
And naturally I can condense that down to just price
now whenever our root handler creates the charge with the just API or seeing the stripe API it's gonna
put that randomly generated amount inside there times 100 so after we make that request we're then going
to write out some code right here to get a list of the 10 most recent charges we have created and inside
that list we will try to find a charge with a price equal to or an amount equal to price times 100.
So how do we list out all the 10 most recent charges.
Well we're just looking at the API for a moment to go so we're going to use stripe charges dot list
and if we want to we could put in the optional Limit amount right there so limit is the number of recent
charges we want to get.
The default is 10 but that can't go up to 100.
Then one thing for you to be aware of is that in the response we get back from that call the list of
charges is going to be nested on this data property.
It's going to take a look at the data property.
We will iterate through that thing.
Take a look at each charge and try to find one with the correct amount OK.
So after we make our request I'll then define stripe charges and that will be a weight stripe that charges
that list.
And again if we wanted to we could increase the limit here say up to 50 the limit that we use right
here really just comes down to how often we expect to be running multiple copies of this test suite
at the same time.
If for some reason we are running 10 copies of this test suite at the same time if we rely upon the
default value of 10 right here as opposed to 50 then it's possible that when we go to fetch our list
of charges we might accidentally push out the charge so we are looking for.
So by increasing this to 50 it pretty much reduces the of that to near zero.
Now we're going to iterate over stripe charges dot data and try to find the appropriate charge.
I'll say stripe charge is stripe charges dot data dot find and for every charge I want to iterate over
each one and I want to return true for the first charge that has an amount to property because remember
they have the amount property equal to our price times 100 language return charged dot amount equal
to Rice times 100.
Now we should be able to expect that stripe charge to be defined
right now.
This test is really just going to make sure that we create a charge with the appropriate amount assigned
to it.
Let's save this and go back over to our terminal and see how we're doing
you'll notice that it takes a little bit longer to run that test file now because we are reaching out
to the real stripe API.
But it does look like our test passed awesome.
Now if you want to try to make this thing fail we could go back over to our right handler itself.
So here's the root handler.
I'll go down to our code where we create the charge and I'll comment that out.
Now we are not creating a charge at all.
And that means that when we tried to go to get our list of most recent charges we should not find one
with the appropriate price.
And of course that should make our test fail.
And there we go.
All right.
Well this definitely works.
Now if we wanted to go too uncommon that by the way and now if we wanted to back inside of our test
file we could take a deeper look at the strike charge object and make some more assertions about it.
So for example we could make sure that it has the appropriate currency.
We can make sure that it's got the correct somehow inspect the token or something like that.
Maybe you just take a look at the currency would be enough.
It's all do and expect stripe charge dot currency to equal USD.
It is possible for strike charge to be undefined by the way because we are using a fine statement right
here.
So once again right after a strike charge will put in the exclamation to tell typescript don't sweat
it.
We technically are checking to make sure that the value is defined online right above typescript just
doesn't really know how to interpret that line they'll save that and run it and there we go.
All right.
So again it is really up to you whether you want to use a mocked version of Stripe or if you want to
use the real version.
Personally I like to use the real version because even though it's a little bit slower.
Well really a lot slower to run.
It definitely is far more realistic and I make sure that my code is working as expected.
The other nice thing here is that we can add in a different token.
So maybe a completely invalid token and we can make sure that our root handler handles that in some
appropriate fashion.
It might be kind of hard to test out an invalid token if we were mocking out the API because we might
not really know how to interpret a response from the API or wow the API is really going to respond if
we give an invalid token OK.
That is it for our more realistic test.
So take a pause right here and move on in just a moment.