1 00:00:00,640 --> 00:00:03,439 Contract testing is a powerful concept. 2 00:00:03,439 --> 00:00:05,450 In contract testing we're verifying that 3 00:00:05,450 --> 00:00:07,939 an API does what a contract says that it 4 00:00:07,939 --> 00:00:10,040 will do. This contract could be something 5 00:00:10,040 --> 00:00:11,780 like documentation, but it's usually 6 00:00:11,780 --> 00:00:13,849 defined with a schema. So in this video 7 00:00:13,849 --> 00:00:15,820 we're going to look at how we can use 8 00:00:15,820 --> 00:00:19,010 tv4 inside of Postman to validate some 9 00:00:19,010 --> 00:00:21,380 API schemas. And a schema is just a way 10 00:00:21,380 --> 00:00:23,030 of defining the rules at different parts 11 00:00:23,030 --> 00:00:25,100 of the API say they will conform to, so 12 00:00:25,100 --> 00:00:27,260 it's a way of defining a contract. So for 13 00:00:27,260 --> 00:00:28,580 example you could have a field that 14 00:00:28,580 --> 00:00:30,200 comes back from the API, and the schema 15 00:00:30,200 --> 00:00:32,750 might say this field must be a string. If 16 00:00:32,750 --> 00:00:34,640 the API was to return another data type 17 00:00:34,640 --> 00:00:36,710 for that field, say an integer it would 18 00:00:36,710 --> 00:00:38,780 be violating the contract that has been 19 00:00:38,780 --> 00:00:41,210 set up in the schema. Schemas are fairly 20 00:00:41,210 --> 00:00:42,860 common in APIs as they allow you to 21 00:00:42,860 --> 00:00:44,300 better know and understand what exactly 22 00:00:44,300 --> 00:00:47,270 an API should be doing. Now this might 23 00:00:47,270 --> 00:00:49,400 all be confusing, so let's take a look at 24 00:00:49,400 --> 00:00:52,790 it in practice. I have here a call to the 25 00:00:52,790 --> 00:00:56,540 Star Wars API set up, and this API 26 00:00:56,540 --> 00:00:58,970 actually publicly provides us with its 27 00:00:58,970 --> 00:01:00,950 schema. So let's take a look at it, we'll 28 00:01:00,950 --> 00:01:02,810 get rid of this and instead we'll put 29 00:01:02,810 --> 00:01:05,599 schema in here, and we'll send that 30 00:01:05,599 --> 00:01:07,670 request, and that gives us back the 31 00:01:07,670 --> 00:01:09,890 schema, so it shows us what fields are 32 00:01:09,890 --> 00:01:12,650 required for this API, and then it shows 33 00:01:12,650 --> 00:01:14,960 what each of these fields should have 34 00:01:14,960 --> 00:01:16,400 what properties they should have. So the 35 00:01:16,400 --> 00:01:18,560 name field should come back as a string. 36 00:01:18,560 --> 00:01:21,430 So let's actually just copy this, and 37 00:01:21,430 --> 00:01:25,490 let's go over to tests here and we'll 38 00:01:25,490 --> 00:01:29,470 create a variable, we'll call it SW 39 00:01:29,470 --> 00:01:33,710 schema, and we'll paste in the schema 40 00:01:33,710 --> 00:01:37,310 that we got back from the API. Now 41 00:01:37,310 --> 00:01:39,229 Postman gives us a way to validate 42 00:01:39,229 --> 00:01:42,590 against a schema using library, it's a 43 00:01:42,590 --> 00:01:44,780 JavaScript validation library called tv4. 44 00:01:44,780 --> 00:01:47,150 So let's create a test that uses that, so 45 00:01:47,150 --> 00:01:51,970 PM test and let's call it schema 46 00:01:51,970 --> 00:01:56,600 validation, and here give it a function 47 00:01:56,600 --> 00:02:00,380 and then inside of our test here let's 48 00:02:00,380 --> 00:02:02,990 create a constant called validation 49 00:02:02,990 --> 00:02:08,840 results. And for this we will call tv4 50 00:02:08,840 --> 00:02:13,459 dot balla date result, and inside of here 51 00:02:13,459 --> 00:02:13,970 we're 52 00:02:13,970 --> 00:02:18,980 take the response dot JSON, and we're 53 00:02:18,980 --> 00:02:21,500 going to validate that against this 54 00:02:21,500 --> 00:02:25,160 schema that we made, so SW schema the one 55 00:02:25,160 --> 00:02:27,650 that we've defined up here. And then 56 00:02:27,650 --> 00:02:32,030 we'll also say false and true to fill 57 00:02:32,030 --> 00:02:33,680 out the other arguments. So this is just 58 00:02:33,680 --> 00:02:36,950 saying whether we want to fail if there 59 00:02:36,950 --> 00:02:39,140 is parameters that we don't expect in 60 00:02:39,140 --> 00:02:41,690 there. And we do so we'll put that in as 61 00:02:41,690 --> 00:02:44,990 true. And then what we expect out of this, 62 00:02:44,990 --> 00:02:49,070 so PM dot expect, we expect this 63 00:02:49,070 --> 00:02:53,959 validation result here to the valid to 64 00:02:53,959 --> 00:02:56,450 come back as valid, so validation result 65 00:02:56,450 --> 00:03:02,630 valid should be dot to be true. So we 66 00:03:02,630 --> 00:03:05,600 expect it to come back as true. And then 67 00:03:05,600 --> 00:03:08,330 let's put a closing bracket here. N,ow 68 00:03:08,330 --> 00:03:10,220 we'll change this so instead of schema 69 00:03:10,220 --> 00:03:13,040 let's look at people slash one and let's 70 00:03:13,040 --> 00:03:16,190 send that request off. And you can see 71 00:03:16,190 --> 00:03:18,140 that the test results the schema 72 00:03:18,140 --> 00:03:20,540 validation has passed. So it looked at 73 00:03:20,540 --> 00:03:22,700 this response, it looked at each of the 74 00:03:22,700 --> 00:03:24,050 fields in this response, it said okay 75 00:03:24,050 --> 00:03:25,670 those are all all the required fields 76 00:03:25,670 --> 00:03:27,680 are there and they all come back with 77 00:03:27,680 --> 00:03:30,230 the correct data type. So now what 78 00:03:30,230 --> 00:03:32,870 happens if we change something, so I 79 00:03:32,870 --> 00:03:35,000 don't know let's look at skin color here, 80 00:03:35,000 --> 00:03:36,709 and instead of saying we expect it to be 81 00:03:36,709 --> 00:03:40,610 a string let's tell it that we expect it 82 00:03:40,610 --> 00:03:43,370 to be an int. So let's do that and let's 83 00:03:43,370 --> 00:03:46,459 send the request. You can see that now it 84 00:03:46,459 --> 00:03:49,250 has failed with a validation error. So 85 00:03:49,250 --> 00:03:51,650 what we got back in our body for skin 86 00:03:51,650 --> 00:03:53,720 color was a string, but the schema was 87 00:03:53,720 --> 00:03:55,430 saying it should be an int, and that is 88 00:03:55,430 --> 00:03:57,709 causing a mismatch so it's failing. So 89 00:03:57,709 --> 00:03:59,120 let's just change this back to string 90 00:03:59,120 --> 00:04:02,360 and everything should be fine again. So 91 00:04:02,360 --> 00:04:05,030 this is a way of defining a contract, the 92 00:04:05,030 --> 00:04:06,799 schema is the contract this is what this 93 00:04:06,799 --> 00:04:09,080 API should do, things that should always 94 00:04:09,080 --> 00:04:12,799 be true in this API. And we can use this 95 00:04:12,799 --> 00:04:15,470 tv4 library in Postman to very quickly 96 00:04:15,470 --> 00:04:19,010 see that our API is indeed sending all 97 00:04:19,010 --> 00:04:21,079 the correct structure and data back that 98 00:04:21,079 --> 00:04:22,640 we need. So this is a very powerful 99 00:04:22,640 --> 00:04:24,620 validation tool, it's a very powerful 100 00:04:24,620 --> 00:04:27,139 concept with contract testing. 101 00:04:27,139 --> 00:04:29,319 Something that is very useful to us. 102 00:04:29,319 --> 00:04:32,659 We're coming to the end of our time 103 00:04:32,659 --> 00:04:34,520 together in this course. And so in the 104 00:04:34,520 --> 00:04:36,590 next video we'll wrap things up and pull 105 00:04:36,590 --> 00:04:41,590 everything together in a conclusion.