Welcome to this video on testing GET
requests. GET requests are probably the
most common requests you'll see. You
might think they're pretty easy to test
right? You send a request to the server
that you get back what you asked for,
but right there is one of the challenges
already. How do you know what you should
get back? What do you do if you get
something unexpected? Did you send the
request in the wrong format, or did the
service or API do something wrong? Well
there's a number of heuristics we can
use when exploring something through an
API, but instead of just talking about
them let's look at an example. So we'll
use this site here, SW API Co and it's
got the Star Wars API for us, and so we
can scroll down here and we can see that
we've got the result of people slash 1
showing here. So we have Luke Skywalker,
and we can see some information about
him, and where he lives, and so on. So
let's use heuristic here, let's check
planet slash 1, so we have people slash 1
but instead let's put in planets slash 1,
and we'll send that request. And when we
get back here is some information about
this planet. And so if we go down and
look in the resident section here, we can
see that people slash 1 is in that
planet, as we would expect. If Luke lives
on this planet then he should be one of
the residents of this planet, and so what
we've done here is a check for
consistency. So if there's a relationship
between two objects, we're checking is
that relationship define consistently on
both of those objects. So we could also
do the same thing for the films, or the
species, etc, and other information in
this API, and make sure that the
relationship between each of these and
Luke is correctly defined. So now let's
look at a little bit of a different
example of checking for consistency.
Let's do this request. We will change the
URL here to just people okay, and we'll
send that request. And what we get back
here is a list of all the people in the
system. Now we can see here the count
says 87, so I would indicate there's 87
entries in the database for people. Let's
try something interesting, let's try
people
slash 88 and see what happens. So we'll
send that request, and interestingly we
get something back. Now it looks like
there's some inconsistency here, and if
we were testing we'd certainly want to
dig in a bit more and see what's going
on.
Maybe there's a missing person somewhere,
a missing number somewhere in the
database,
maybe there's actually 88 and the bulk
call to people is wrong? But if we were
testing this we would dig in and try to
find out what's going on, but this is an
example of consistency. We expect that if
it says there's 87 calls, that the URLs
will resolve consistently. Now this API
is an open API, so there's no
authentication or hidden items, so we
can't actually see this in action. But an
important consideration in API testing
is to make sure that hidden resources
aren't accidentally revealed. So for
example this API allows us to search for
things. So sometimes using parameters
like search can allow the wrong things
to be revealed. So let's just look at a
bit of an example here. We'll change this
URL to use this funny little format, and
we'll talk about this more later. But
we'll say search equals hidden, so
basically we're saying I want to search
for the term hidden and see what happens.
So if we send that request off we get
back empty, so there's no search results
for hidden, which is fine, this is just an
example. But what if there was something
called like hidden name or something
like that, and it was supposed to be
hidden behind some kind of
authentication. If our search result
didn't respect that authentication we
might see it. So this is an example of
the kinds of things we want to consider,
are there different paths to get to the
same data? And could it be problematic if
we go through those different paths?
There of course many other things that
we could check as well. For example we
could look at the intended structure of
the data, and actually this API gives us
a really nice way to do that. So we can
look at people slash schema and send
that request, and it shows us here the
expected format of the data. So this is
something that's really helpful if we
wanted to check that each of the people
in the system was correctly defined
according to the schema. So other things
we could check for is
how the API handles bad requests, we
could look at authentication, we could
look at security, and performance, and the
list goes on. But we won't get into
specific examples of each of those at
this time, I will touch on some of that
stuff a little more later on in the
course.
So although we might think that all
we're doing is getting some data back
when we're testing a GET call. Hopefully
this video helps to illustrate that
there's a lot more to it, and helps to
stimulate your thinking on some of the
possibilities of the things that there
are to check. As with most things in
testing you're only limited by your
imagination. So try those GET calls, think
like an explorer and you might be
surprised at what you can find out about
your API. In the next video, we'll dig in
a little more into GET calls and how to
use parameters in them, so hope to see
you there.