1 00:00:01,170 --> 00:00:06,060 The test we have put together that relies upon mocking the stripe client definitely works. 2 00:00:06,510 --> 00:00:10,840 However I thought would be fun to take a look at an alternative way of putting this test together. 3 00:00:11,030 --> 00:00:16,290 And in this alternate way we're going to allow in the test environment our root handler to talk directly 4 00:00:16,290 --> 00:00:18,510 to the real stripe API. 5 00:00:18,510 --> 00:00:22,500 And so this will ensure that we are really creating a charge with all the correct values and that stripe 6 00:00:22,500 --> 00:00:25,330 has actually successfully gradient for us. 7 00:00:25,440 --> 00:00:26,960 Now this really is optional. 8 00:00:26,970 --> 00:00:30,630 I'm really just going to show you this alternative approach and it's really up to you which approach 9 00:00:30,660 --> 00:00:32,090 you want to use. 10 00:00:32,220 --> 00:00:37,350 Although I will say it is kind of an either or you're going to either use this mock approach or you're 11 00:00:37,350 --> 00:00:42,480 going to use this more realistic way that I'm about to show you the downside to the realistic approach 12 00:00:42,540 --> 00:00:46,560 is that these tests are going to take a little bit longer to run because we do have to make a request 13 00:00:46,560 --> 00:00:50,710 to the real stripe API OK so enough of that. 14 00:00:50,730 --> 00:00:53,070 Let's take a look at how you put this together. 15 00:00:53,070 --> 00:00:56,850 The person you'd want to do is make sure that we remove our stripe Mark. 16 00:00:57,090 --> 00:00:59,250 We don't want to mark out that client anymore. 17 00:00:59,250 --> 00:01:04,830 We want to use the real stripe API so to remove that at the very top of our test file. 18 00:01:05,190 --> 00:01:13,690 I will remove the just mock statement and then inside of my MOX directory I'm going to rename that striped 19 00:01:13,690 --> 00:01:19,340 T S file to striped T S dot old to the dot. 20 00:01:19,340 --> 00:01:27,040 Hold on there just just changes the extension just so we do not accidentally load up that file OK. 21 00:01:27,050 --> 00:01:33,110 Next up we need to make sure that our local test copy or the in a test instance of the stripe client 22 00:01:33,110 --> 00:01:38,960 we create has access to our stripe API key remember that we did set up a Cuban net a secret to store 23 00:01:38,990 --> 00:01:43,820 our key but that secret is only accessible inside of our Cuban cities cluster and our tests are running 24 00:01:43,820 --> 00:01:45,330 outside of the cluster. 25 00:01:45,380 --> 00:01:48,650 So in our tests are running we do not have access to the key. 26 00:01:48,650 --> 00:01:52,700 Now ideally we would store this key inside of an environment variable on your local machine. 27 00:01:53,210 --> 00:01:57,740 However setting up environment variables is very different depending upon your operating system and 28 00:01:57,740 --> 00:01:59,930 even what Shell you use. 29 00:01:59,930 --> 00:02:04,370 So ideally you would set this up as an environment variable but I will leave that as an exercise to 30 00:02:04,370 --> 00:02:09,350 you and instead you and I are just going to cheat we're going to directly set the environment or the 31 00:02:09,410 --> 00:02:15,380 stripe API key inside of our test setup dot t s file very similar to how we set some other environment 32 00:02:15,380 --> 00:02:26,860 variables inside of here right above the before all statement I'm going to define stripe key and then 33 00:02:26,860 --> 00:02:33,910 I'm going to assign my api key to that variable so as a reminder you can get that from the stripe dashboard 34 00:02:34,570 --> 00:02:38,370 by going to developers and then api keys and you'll see these secret key right there. 35 00:02:38,410 --> 00:02:45,800 That's the one that we want to use paste that in like so those that we are not placing that environment 36 00:02:45,800 --> 00:02:47,620 variable next to all the others. 37 00:02:47,670 --> 00:02:52,130 The reason for that is that we have to define this API key as soon as possible because it's going to 38 00:02:52,130 --> 00:02:59,880 be used the instant that we first require in the striped T S file inside of our s our C directory gang 39 00:03:00,020 --> 00:03:04,390 and to say that file and then close it. 40 00:03:04,400 --> 00:03:11,720 So now whenever we run our test suite and we run that test right here though our success case tests 41 00:03:12,320 --> 00:03:16,820 when we make our request that's going to reach out to the real stripe API. 42 00:03:17,010 --> 00:03:20,700 We are still making some expectations right here however that is assuming that we are working with a 43 00:03:20,700 --> 00:03:26,790 mock function trying to delete all those expectations and we now need to figure out some other way to 44 00:03:26,790 --> 00:03:32,100 reach out to the stripe API and make sure that we actually are creating a charge with all the correct 45 00:03:32,130 --> 00:03:35,250 attributes because again that is the whole goal of this test. 46 00:03:35,370 --> 00:03:41,140 We want to make sure that a charge was created and that is can you just a little bit challenging. 47 00:03:41,140 --> 00:03:44,890 So let me show you a diagram just to summarize what we have to do and help you understand why it is 48 00:03:44,890 --> 00:03:47,680 kind of a challenging process. 49 00:03:47,840 --> 00:03:48,050 OK. 50 00:03:48,080 --> 00:03:50,100 So in this diagram we've got our test file. 51 00:03:50,150 --> 00:03:56,410 We've got a root handler in the stripe API so inside of our test file we are going to more or less make 52 00:03:56,440 --> 00:03:57,820 a request to Overton throughout. 53 00:03:57,820 --> 00:04:04,340 Handler will include a token and some order I.D. that root handler is going to run and then it's simply 54 00:04:04,370 --> 00:04:07,410 in time it's going to reach out to the real stripe API. 55 00:04:07,730 --> 00:04:14,280 It'll provide some token some amount some currency for a charge to be created then the stripe API is 56 00:04:14,280 --> 00:04:19,560 going to immediately return some details about the charge that was just made that these details about 57 00:04:19,560 --> 00:04:21,000 the charge was just created. 58 00:04:21,090 --> 00:04:25,980 That is what we would love to get access to inside of our test file because then we could write out 59 00:04:25,980 --> 00:04:31,410 some expectations and make sure that the charge was created that was created as the correct amount as 60 00:04:31,410 --> 00:04:32,460 the correct. 61 00:04:32,640 --> 00:04:35,530 Who knows what else be the correct date or something like that. 62 00:04:35,550 --> 00:04:39,360 In other words we would really like to get information about this charge into our test file so we could 63 00:04:39,360 --> 00:04:46,350 write out some expectations but right now our root handler does not return any information about the 64 00:04:46,350 --> 00:04:49,430 charge that was created that does not happen right now. 65 00:04:49,740 --> 00:04:52,080 Of course we could very easily change that. 66 00:04:52,110 --> 00:05:00,040 Without a doubt back inside of our root handler so here's new to us here's a recreate the charge. 67 00:05:00,160 --> 00:05:04,750 We could definitely take some information about the charge that was made and then send it back to ever 68 00:05:04,780 --> 00:05:09,310 made this request and then inside of a request to or is it gives me inside of our test file. 69 00:05:09,340 --> 00:05:13,590 We can receive that information and make sure that the charge was made has some correct attributes. 70 00:05:13,870 --> 00:05:20,110 But if we did that we would be changing the implementation of our code just to better suit our test. 71 00:05:20,110 --> 00:05:22,090 And that is usually a really bad sign. 72 00:05:22,090 --> 00:05:27,070 We usually do not want to make any changes to our code just to make it easy user to write out some very 73 00:05:27,070 --> 00:05:33,060 particular test rather than trying to take this information about the charge that was created and fought 74 00:05:33,060 --> 00:05:34,150 it back over the test file. 75 00:05:34,160 --> 00:05:38,360 We are gonna figure out a different way to do this we're gonna figure out a different way to make sure 76 00:05:38,360 --> 00:05:44,150 that our test file can get some details and make sure that the charge was created has the correct properties. 77 00:05:44,150 --> 00:05:45,760 So how are we gonna do that. 78 00:05:45,770 --> 00:05:51,590 Well let's take another look at the stripe API back at the stripe API documentation. 79 00:05:51,590 --> 00:05:59,950 Again this is at docs API charges weird took to took a look at the created charge and points. 80 00:06:00,050 --> 00:06:02,900 There's another endpoint to retrieve a charge. 81 00:06:02,950 --> 00:06:07,540 So this will get information about a charge that has been created but we have to provide the idea of 82 00:06:07,540 --> 00:06:08,610 the charge. 83 00:06:08,800 --> 00:06:13,720 Once again we currently are not really able to communicate any information about the charge itself from 84 00:06:13,720 --> 00:06:19,610 the root handler to the test file and it's unlikely that we will ever change that so unfortunately this 85 00:06:19,610 --> 00:06:22,080 retrieve a charge and point is not very helpful. 86 00:06:22,340 --> 00:06:26,280 But there is another one that we might be able to use if we get just a little bit clever. 87 00:06:26,280 --> 00:06:29,810 There is an end point of list all charges by default. 88 00:06:29,810 --> 00:06:35,330 This will give us the previous 10 charges that have been created and we could increase that up to 100 89 00:06:35,420 --> 00:06:37,620 if we wanted to. 90 00:06:37,790 --> 00:06:39,170 So here's my idea. 91 00:06:40,150 --> 00:06:44,530 We're gonna have our test file make this request the root handler will send that off to stripe. 92 00:06:44,530 --> 00:06:48,880 We'll get the response from stripe back and eventually the root handler will send back a message of 93 00:06:49,510 --> 00:06:51,460 success true to our test file. 94 00:06:52,330 --> 00:06:59,480 After we get that success back we're then going to have our test itself reach out to the stripe API. 95 00:06:59,650 --> 00:07:04,610 We're going to request a list of the 10 most recent charges that have been created. 96 00:07:04,790 --> 00:07:14,490 We'll say give me a list of the 10 most recent charges the stripe API is going to respond with that 97 00:07:14,490 --> 00:07:22,030 list of 10 charges so list of 10 most recent and then inside of our test file. 98 00:07:22,120 --> 00:07:25,500 We're going to take a look at those 10 most recent charges. 99 00:07:25,510 --> 00:07:32,810 We're going to make sure that there was one charge that has the what looks like the correct set of properties. 100 00:07:33,010 --> 00:07:38,320 So perhaps it has maybe some correct token some concurrency or something like that. 101 00:07:38,390 --> 00:07:39,680 Now this would definitely work. 102 00:07:39,680 --> 00:07:44,780 But remember that token and the currency are always gonna be the same for every single test run. 103 00:07:44,780 --> 00:07:49,280 So we could potentially be taking a look at some data inside this list of 10 most recent charges that 104 00:07:49,280 --> 00:07:54,190 is stale or belongs to some tests we ran say some minutes ago. 105 00:07:54,320 --> 00:07:58,910 So we need to make sure that whenever we create this charge there's some unique identifying information 106 00:07:58,940 --> 00:08:04,280 inside of it that we can use to identify that charge inside this list of 10 most recent charges inside 107 00:08:04,280 --> 00:08:08,790 of our test file so we can get some unique information inside there. 108 00:08:08,810 --> 00:08:13,230 Well we're going to use that currency remember that inside of a test file. 109 00:08:13,230 --> 00:08:16,920 We are creating the order that we are trying to purchase right now. 110 00:08:16,920 --> 00:08:22,830 The order is hardcoded to be 20 U.S. dollars so instead of using a hardcoded value of twenty dollars 111 00:08:23,100 --> 00:08:29,220 we're going to instead randomly generate a price for the order instead we will randomly generate a price 112 00:08:29,340 --> 00:08:35,610 assign it to the order and then when that root handler makes the request to purchase or create the charge 113 00:08:35,970 --> 00:08:39,140 we will see that randomly generated amount inside there. 114 00:08:39,150 --> 00:08:41,850 So we'll be like some amount like that. 115 00:08:42,040 --> 00:08:48,610 Then when we get back our list of 10 most recent charges we can try to find a charge with that amount 116 00:08:48,930 --> 00:08:50,430 to some amount of 9 to 2. 117 00:08:50,430 --> 00:08:51,320 Blah blah blah. 118 00:08:51,550 --> 00:08:56,170 And if we find a charge in the list of charges with that amount that means that we must have successfully 119 00:08:56,170 --> 00:08:59,020 created the charge inside the root handler. 120 00:08:59,020 --> 00:09:03,480 And at no point time will we have had to change any code or return change the return value of drought 121 00:09:03,490 --> 00:09:06,950 handler just to better suit our test OK. 122 00:09:06,980 --> 00:09:11,720 So I know this entire setup is kind of complicated but again I just want to show you this alternate 123 00:09:11,780 --> 00:09:12,750 approach. 124 00:09:12,860 --> 00:09:15,500 Let's take a pause right here and implement this in the next video.