1
00:00:00,420 --> 00:00:02,730
Welcome to this video on testing GET

2
00:00:02,730 --> 00:00:05,640
requests. GET requests are probably the

3
00:00:05,640 --> 00:00:07,740
most common requests you'll see. You

4
00:00:07,740 --> 00:00:09,210
might think they're pretty easy to test

5
00:00:09,210 --> 00:00:11,640
right? You send a request to the server

6
00:00:11,640 --> 00:00:13,320
that you get back what you asked for,

7
00:00:13,320 --> 00:00:14,790
but right there is one of the challenges

8
00:00:14,790 --> 00:00:17,099
already. How do you know what you should

9
00:00:17,099 --> 00:00:18,570
get back? What do you do if you get

10
00:00:18,570 --> 00:00:20,249
something unexpected? Did you send the

11
00:00:20,249 --> 00:00:21,900
request in the wrong format, or did the

12
00:00:21,900 --> 00:00:24,119
service or API do something wrong? Well

13
00:00:24,119 --> 00:00:25,529
there's a number of heuristics we can

14
00:00:25,529 --> 00:00:26,999
use when exploring something through an

15
00:00:26,999 --> 00:00:28,859
API, but instead of just talking about

16
00:00:28,859 --> 00:00:31,319
them let's look at an example. So we'll

17
00:00:31,319 --> 00:00:36,210
use this site here, SW API Co and it's

18
00:00:36,210 --> 00:00:39,629
got the Star Wars API for us, and so we

19
00:00:39,629 --> 00:00:42,899
can scroll down here and we can see that

20
00:00:42,899 --> 00:00:45,480
we've got the result of people slash 1

21
00:00:45,480 --> 00:00:48,690
showing here. So we have Luke Skywalker,

22
00:00:48,690 --> 00:00:51,660
and we can see some information about

23
00:00:51,660 --> 00:00:54,929
him, and where he lives, and so on. So

24
00:00:54,929 --> 00:00:58,980
let's use heuristic here, let's check

25
00:00:58,980 --> 00:01:02,339
planet slash 1, so we have people slash 1

26
00:01:02,339 --> 00:01:05,759
but instead let's put in planets slash 1,

27
00:01:05,759 --> 00:01:09,689
and we'll send that request. And when we

28
00:01:09,689 --> 00:01:11,549
get back here is some information about

29
00:01:11,549 --> 00:01:13,740
this planet. And so if we go down and

30
00:01:13,740 --> 00:01:16,110
look in the resident section here, we can

31
00:01:16,110 --> 00:01:18,450
see that people slash 1 is in that

32
00:01:18,450 --> 00:01:21,509
planet, as we would expect. If Luke lives

33
00:01:21,509 --> 00:01:24,329
on this planet then he should be one of

34
00:01:24,329 --> 00:01:26,340
the residents of this planet, and so what

35
00:01:26,340 --> 00:01:27,600
we've done here is a check for

36
00:01:27,600 --> 00:01:29,399
consistency. So if there's a relationship

37
00:01:29,399 --> 00:01:31,979
between two objects, we're checking is

38
00:01:31,979 --> 00:01:34,500
that relationship define consistently on

39
00:01:34,500 --> 00:01:36,899
both of those objects. So we could also

40
00:01:36,899 --> 00:01:38,490
do the same thing for the films, or the

41
00:01:38,490 --> 00:01:40,500
species, etc, and other information in

42
00:01:40,500 --> 00:01:42,540
this API, and make sure that the

43
00:01:42,540 --> 00:01:44,460
relationship between each of these and

44
00:01:44,460 --> 00:01:47,009
Luke is correctly defined. So now let's

45
00:01:47,009 --> 00:01:48,180
look at a little bit of a different

46
00:01:48,180 --> 00:01:50,340
example of checking for consistency.

47
00:01:50,340 --> 00:01:53,250
Let's do this request. We will change the

48
00:01:53,250 --> 00:01:57,030
URL here to just people okay, and we'll

49
00:01:57,030 --> 00:01:59,520
send that request. And what we get back

50
00:01:59,520 --> 00:02:03,329
here is a list of all the people in the

51
00:02:03,329 --> 00:02:06,090
system. Now we can see here the count

52
00:02:06,090 --> 00:02:09,300
says 87, so I would indicate there's 87

53
00:02:09,300 --> 00:02:12,030
entries in the database for people. Let's

54
00:02:12,030 --> 00:02:13,620
try something interesting, let's try

55
00:02:13,620 --> 00:02:14,610
people

56
00:02:14,610 --> 00:02:18,270
slash 88 and see what happens. So we'll

57
00:02:18,270 --> 00:02:21,000
send that request, and interestingly we

58
00:02:21,000 --> 00:02:23,610
get something back. Now it looks like

59
00:02:23,610 --> 00:02:25,440
there's some inconsistency here, and if

60
00:02:25,440 --> 00:02:26,820
we were testing we'd certainly want to

61
00:02:26,820 --> 00:02:28,530
dig in a bit more and see what's going

62
00:02:28,530 --> 00:02:28,920
on.

63
00:02:28,920 --> 00:02:30,960
Maybe there's a missing person somewhere,

64
00:02:30,960 --> 00:02:32,430
a missing number somewhere in the

65
00:02:32,430 --> 00:02:33,060
database,

66
00:02:33,060 --> 00:02:35,760
maybe there's actually 88 and the bulk

67
00:02:35,760 --> 00:02:38,850
call to people is wrong? But if we were

68
00:02:38,850 --> 00:02:41,010
testing this we would dig in and try to

69
00:02:41,010 --> 00:02:42,540
find out what's going on, but this is an

70
00:02:42,540 --> 00:02:46,380
example of consistency. We expect that if

71
00:02:46,380 --> 00:02:48,420
it says there's 87 calls, that the URLs

72
00:02:48,420 --> 00:02:52,290
will resolve consistently. Now this API

73
00:02:52,290 --> 00:02:53,940
is an open API, so there's no

74
00:02:53,940 --> 00:02:55,980
authentication or hidden items, so we

75
00:02:55,980 --> 00:02:57,780
can't actually see this in action. But an

76
00:02:57,780 --> 00:02:59,970
important consideration in API testing

77
00:02:59,970 --> 00:03:02,070
is to make sure that hidden resources

78
00:03:02,070 --> 00:03:04,560
aren't accidentally revealed. So for

79
00:03:04,560 --> 00:03:06,570
example this API allows us to search for

80
00:03:06,570 --> 00:03:08,250
things. So sometimes using parameters

81
00:03:08,250 --> 00:03:10,290
like search can allow the wrong things

82
00:03:10,290 --> 00:03:12,090
to be revealed. So let's just look at a

83
00:03:12,090 --> 00:03:15,000
bit of an example here. We'll change this

84
00:03:15,000 --> 00:03:17,220
URL to use this funny little format, and

85
00:03:17,220 --> 00:03:19,110
we'll talk about this more later. But

86
00:03:19,110 --> 00:03:22,709
we'll say search equals hidden, so

87
00:03:22,709 --> 00:03:24,330
basically we're saying I want to search

88
00:03:24,330 --> 00:03:26,550
for the term hidden and see what happens.

89
00:03:26,550 --> 00:03:29,670
So if we send that request off we get

90
00:03:29,670 --> 00:03:31,830
back empty, so there's no search results

91
00:03:31,830 --> 00:03:33,930
for hidden, which is fine, this is just an

92
00:03:33,930 --> 00:03:36,660
example. But what if there was something

93
00:03:36,660 --> 00:03:38,370
called like hidden name or something

94
00:03:38,370 --> 00:03:40,080
like that, and it was supposed to be

95
00:03:40,080 --> 00:03:42,540
hidden behind some kind of

96
00:03:42,540 --> 00:03:44,850
authentication. If our search result

97
00:03:44,850 --> 00:03:46,980
didn't respect that authentication we

98
00:03:46,980 --> 00:03:50,700
might see it. So this is an example of

99
00:03:50,700 --> 00:03:52,500
the kinds of things we want to consider,

100
00:03:52,500 --> 00:03:54,510
are there different paths to get to the

101
00:03:54,510 --> 00:03:57,720
same data? And could it be problematic if

102
00:03:57,720 --> 00:03:59,040
we go through those different paths?

103
00:03:59,040 --> 00:04:01,140
There of course many other things that

104
00:04:01,140 --> 00:04:03,150
we could check as well. For example we

105
00:04:03,150 --> 00:04:05,010
could look at the intended structure of

106
00:04:05,010 --> 00:04:07,470
the data, and actually this API gives us

107
00:04:07,470 --> 00:04:10,020
a really nice way to do that. So we can

108
00:04:10,020 --> 00:04:13,590
look at people slash schema and send

109
00:04:13,590 --> 00:04:16,560
that request, and it shows us here the

110
00:04:16,560 --> 00:04:19,380
expected format of the data. So this is

111
00:04:19,380 --> 00:04:20,880
something that's really helpful if we

112
00:04:20,880 --> 00:04:23,279
wanted to check that each of the people

113
00:04:23,279 --> 00:04:24,899
in the system was correctly defined

114
00:04:24,899 --> 00:04:27,478
according to the schema. So other things

115
00:04:27,478 --> 00:04:28,449
we could check for is

116
00:04:28,449 --> 00:04:30,550
how the API handles bad requests, we

117
00:04:30,550 --> 00:04:32,020
could look at authentication, we could

118
00:04:32,020 --> 00:04:33,669
look at security, and performance, and the

119
00:04:33,669 --> 00:04:35,680
list goes on. But we won't get into

120
00:04:35,680 --> 00:04:37,270
specific examples of each of those at

121
00:04:37,270 --> 00:04:39,069
this time, I will touch on some of that

122
00:04:39,069 --> 00:04:40,419
stuff a little more later on in the

123
00:04:40,419 --> 00:04:40,889
course.

124
00:04:40,889 --> 00:04:43,689
So although we might think that all

125
00:04:43,689 --> 00:04:45,550
we're doing is getting some data back

126
00:04:45,550 --> 00:04:47,800
when we're testing a GET call. Hopefully

127
00:04:47,800 --> 00:04:49,659
this video helps to illustrate that

128
00:04:49,659 --> 00:04:52,029
there's a lot more to it, and helps to

129
00:04:52,029 --> 00:04:53,589
stimulate your thinking on some of the

130
00:04:53,589 --> 00:04:55,210
possibilities of the things that there

131
00:04:55,210 --> 00:04:57,430
are to check. As with most things in

132
00:04:57,430 --> 00:04:58,719
testing you're only limited by your

133
00:04:58,719 --> 00:05:01,330
imagination. So try those GET calls, think

134
00:05:01,330 --> 00:05:02,830
like an explorer and you might be

135
00:05:02,830 --> 00:05:04,599
surprised at what you can find out about

136
00:05:04,599 --> 00:05:07,569
your API. In the next video, we'll dig in

137
00:05:07,569 --> 00:05:09,159
a little more into GET calls and how to

138
00:05:09,159 --> 00:05:11,439
use parameters in them, so hope to see

139
00:05:11,439 --> 00:05:16,439
you there.