Detailed Notes
Our journey into Restful API Testing Using RestAssured begins by looking at the different ways in which API testing can be done. Next, we look at how to use tools such as the browser developer tool, Swagger, and Postman to test APIs from a browser. Additionally, we look at how to use libraries like RestAssued and Karate to build continuous integration tests for our code projects. Finally, we wrap up our discussion by showing you how to write RestAssured tests against a real-world scenario.
Restful API Testing Using RestAssured Overview:
Overview of Restful API Different Types of HTTP Requests How to Manually Test a Restful API Use Postman and Swagger Write RestAssured Unit Test What is Restful API
REST APIs provide a flexible, lightweight way to integrate applications, and have emerged as the most common method for connecting components in microservices architectures.
-IBM
HTTP Requests
Get - Requests a representation of the specified resource. Requests using GET should only retrieve data. Post -Submits an entity to the specified resource, often causing a change in state or side effects on the server. Put - Replaces all current representations of the target resource with the request payload. Delete - Deletes the specified resource. - Mozilla
RestAssured
REST Assured is a Java DSL for simplifying testing of REST-based services built on top of HTTP Builder. It supports POST, GET, PUT, DELETE, OPTIONS, PATCH, and HEAD requests and can be used to validate and verify the response of these requests.
- RestAssured
Start with a real-world example
To explain the principles of API testing we decided to begin with a real-world exercise and build out our test cases to support the following scenario. For instance, a company that wants to set up a Tutorial center at a university to help students study. Initially, they build a WS application that records the subjects that will be covered.
The current interface supports:
Create A Tutorial Retrieve All Tutorials Retrieve A Tutorial By Id Update A Tutorials By Id Find All Published Tutorials Find By Title Containing String Delete A Tutorial Delete All Tutorials
Restful API Testing Using RestAssured
Additional Resources
RestAssured Karate Postman Swagger Finally, this series comes from our mentoring/mastermind classes. These classes are virtual meetings that focus on how to improve our technical skills and build our businesses. After all the goals of each member vary. However, this diversity makes for great discussions and a ton of educational value every time we meet. We hope you enjoy viewing this series as much as we enjoy creating it. As always, this may not be all new to you, but we hope it helps you be a better developer.
Transcript Text
[Music] okay our test bringing so let's go look at the console there's our test so we started spring boot reset our data we came in here the first thing we did was a post here's our api we set the context to application json as you can see here our body contains the json object our http response was actually 201 and the application came back was json so if we look this guy should have failed because i said 200 but we did get back the context with our id of three so then when we did our get we now have three records returned so we see that the first post worked and the second post returned all three however the first one failed because we did not get a 200 we actually got a 201 so if i update this to 201 restart and run our resistor demo again and we see everything passed that's because we received a 201 so we got our 200 for our get a 201 for our post and our conditions passed now all right so that's one and two so now let's look at retrieving a tutorial by id and let's look at swagger real quick so retrieving by id so we have to do a get tutorials by id well we know we have one record out there so let's try this guy out real quick and just put one and execute so we have an id a response should come back as 200 and we should return a record and a response record should be of type tutorial and if you look here here is the url that we need to pass so let's look at how we set this up so if we go over back to our code so we have request we have base uri we have get so all this is the same with the exception of our get so get actually now requires an id so we need to put in a token for id and now we need to set the id value so now we need to set a path param and the parameter is going to be our token there id and our value so in this case we want to pass in one just like we did over here so here's our parameters so we set our parameter id as one and we added id to our get so now this looks exactly like what we have here in swagger so now if i save this and run again we create the tutorial we retrieved all tutorials and we retrieved a tutorial by id so if i zoom up the last call here was to our get so we passed in one until we replaced our token we got back at 200 application json we set our path parameter id of 1 and we received back calculus so that worked so far so good pretty straightforward all right so next we want to update by id and as you can see a lot of this is pretty straightforward all you have to do is follow some basic functionality of how the apis are called by id so we already have our id so we've already defined our parameters we've already set our api however in this case we actually are doing a put so if we go look over here if we want to update we need to do a put so put api tutorials id requires the parameter id so all still the same this time though however we need to pass in our body the tutorial value that we want to update and we're going to get back a response again for the output all right so here we have our given we have our log we have our base uri we have our parameter so there's two things we need to set here so one if we look back over here we have to specify the application json so in our setup so we have base uri we have to set the context type the application based on we've got that we've got our path and now we need our body so to do the body we need to specify some context so first we could do the new like we did up here for the post however i want to show you a different way to do this so you can do this another way so here instead of setting the body you can actually set up a json mapper to do that you create a map collection of a string and object and i'm showing you this in case you don't have the pojo or don't have the mapper so if you do a json as map equals new hash map okay and then in here we're going to do json as a map need to do that three times because we need to set the title description and published so json map we need to put we need to put some information into our collection and now here we need to set our values so we know we need title we have our description and we have published so if we don't have the pojo or we don't have the entity being that we need to build this is a way for us to map it back so if we go look here and just look at this example we see we have title description published so we need to provide these values here in our put so we see we have to have string string and true so we're going to come in title string some string and this one will set to false since we know calculus is already published we will change it to something else that's not published so here i'm going to set our book title to 2001 a space odyssey and again a another space novel and save all right so instead of doing the new tutorial i'm actually defining our json mapper now to mimic what we have to send in our header this here now we do not need to set id because id is what we're actually going to pass in as our lookup parameter to set this value all right so we have our log we have our base uri we have our context type we're setting our parameter and now we need to set our body to include our json mapper is based on this map including that that looks good and then we log and we should get 200. so we'll save rerun and all of our test paths let's look at our update here at the end or report so we know one was calculus and math and publish is true we passed in our body of description published in true so this is our json map we specified it as json and we set the path parameter id as one so here's our put and then what came back was id one our new title our new description and published as false okay that gives us four now the rest of these are pretty straightforward so i'm just going to copy these down here and we're just going to knock through them real quick all right so we have five five let's just simplify this for now so five is find all published tutorials and duplicate flagger we want this one api tutorials published there's no parameters there's no body it's a straight up get so we change this to a get tutorials published we don't need body we don't need context we just need the uri and that should return to 200. so that one's pretty straightforward and that would be number five okay save that rerun so that one ran and let's look at the console so as we see here we got back title three four five and six all were published true now if we actually were to reset our test we would only get back one of these because we only had one hitchhiker's guide to the galaxy but it's interesting because we're re-running this test continuously against our in memory database it's just going to keep stacking up these values all right so now let's find a title containing a string so test 6 find by title containing string and ironically enough this is actually the first call we did so if we actually go look back at swagger if we look we do not have a getter for find tutorials by string if we look we have api tutorials and if we expand that we see here that we can pass in a optional title so let's go back over here so here we're going to need a so we can kind of cheat we'll just go back up here we'll need a path parameter and this one will be type and we want to look for zero i want to find the ones with 2001 and we just drop it back down to tutorials so our api we pass in the parameter title we just get api tutorials if you notice we're not actually setting anything here we're just setting the path parameters oops sorry wrong one yep so not path parameters this is actually a because this is a path parameter this is actually a form parameter so slightly different so since this isn't a path but we need to push this with the form so this will be a form parameter now we call get api tutorials so if i run this refresh and run our test again everything passed if you notice we created a tutorial we retrieved all tutorials so we're just stacking up our test so the last one here we were looking for anything with a title of zero and since i restarted our database we got back one record you see here we got back 2001 a space odyssey because this is the only title with the zero if you notice here if we go back one since i restarted the microservice our database reset and we only got back one hitchhiker's guide to the galaxy they're with me we're almost done so next we want to delete an individual tutorial and delete all tutorials so this will be delete a tutorial and this is good for cleanup so if you're running specific test data and you have this option after you set everything up you can go through and delete everything and then validate that your records were deleted all right so again let's look at swagger so we have two deletes here we have one delete all one delete by id we need to pass in a parameter for id and we should get back a 200 that everything was deleted so and this has to be a delete request so instead of get we do delete api tutorials by id api tutorials id now this is not a form perm path because we're updating the id in the path and this will be id and one so delete so we'll delete the first record in the list and actually let's delete the second one so we'll delete two and just test that we deleted this let's go up and verify by id yeah here we are retrieve the tutorial by id so let's copy this guy and add a second test to this one so this will be 7 8 verify tutorial was deleted by id and since we're doing two we'll follow up with two so it should return no record so we should actually get back a 404 for no records found and this delete will actually return us a 204 all right so let's run this this is running our test is complete it deleted our record and we verified it was deleted so the delete is right here so here's our request so we deleted we passed in the url the api with our id of two pathform id2 and we received back a 204. and when we tried to validate it we received a 404 because there was no records found okay and last but not least let's delete all the records and we're going to delete all tutorials and this will be nine don't need that and our delete should be back and 204 double check our swagger delete api tutorials no parameters and it should delete everything all right so if i run this everything work except delete a tutorial that's because we actually had already deleted number two and therefore it's not there so what we need to do for this particular test is restart the database restart the microservice for the api with the database menu once that's restarted then we can rerun the test and everything passed so if we look at our last command here we called our request delete api tutorials everything deleted it returned back to 204 so now if we actually come over here to swagger so i could write one more method to double check this but what we can do is we can go here to get api tutorials click try out hit execute so it returned nothing we have no body alright so that is rest assured in a nutshell so we walk through the different types of commands here so let's go back and just briefly go over this so we went through the different ways you can use rest assured to set up your request header we define our base uri we can set contact type we can pass in a body either through a object or using a json mapper we can post information we can get information we can use the path parameter id to set an id on the url we can validate the statuses of the requests coming back using the status code we can also define our context type within a request and within our response we can also do forms so we can pass form information if it does not need to be in the url and we went through using the delete and verifying a delete so are there any questions so michael i know when it turns green and that's when you know like the api ran successfully so um is there a way like uh whereby you you can let me say manipulate it and and it turns green maybe or maybe you can throw in on a failure in api because then anytime i run it usually most of the time like it comes out green all the time which means it's uh i mean i'm a tester because usually i wouldn't know what goes on behind the scenes so these are all predefined tests so depending upon your test data if you're trying to test to make sure everything returns correctly your validation points in our case here the status code is going to be our assertion so if you're unsure of what the test is checking you can go look at the test and then look at what is being asserted so you could have an assert method here or some type a status code within the rest assured with that being said though you really want your test to always be green because if it's not green then that means that either a code change that was deployed broke something or the requirements that you're actually testing against have changed and you need to go update the test case or test data to reflect the changes to the requirements okay okay any other questions not so much a question as much as just sort of a a statement i think to follow up with these as we you know we've done a couple of these now the tools for testing particularly at this level and it almost it's funny so as i go through some of these you know watch some of these presentations is it's almost an itch to build out proper testing and i think it just points to it's become such a such an easy thing to do in many cases when you include the tools you look at the power of them and how easy it is to just script out some tests it to me it makes more sense than ever for developers to definitely be a part of it and be building out some of their tests at least their unit tests and you know assisting qa more and particularly when you look at like you know sprints and the scrum approach and things like that where it's not a you know sort of like a wall between developers and qa but a partnership um these kind of tools just make this make that much more easy to do and almost hard to argue against it it's like you know how much how much effort is it really going to take other than thinking through some of these tests to build them out and particularly when you're coding them in the first place you almost those things almost fall into place it's you know it's obviously test driven development things like that make that more uh push you to do that but even if you're not taking that approach it seems like you know testing is almost a slam dunk at this point exactly and it really should be because even after i did all the presentations on integrating testing in your development cycle really testing should be a no-brainer at this point i mean we've been in the coding now for well over two decades and this whole idea of we need to separate qa from testing really is a joke at this point really if you want to write good code especially in the microsoft world you have to think from the end point so basically you have to start with your test what it is that you're trying to do and then write your code for it because if you do it the other way you're really risking what is it that this microservice is really going to do for you and the other way of thinking this way is as a developer at the end when you're done writing your code you know how to test your code you know how it was tested now granted you may make mistakes and what you write for your test cases but as you get better at this when you hand it off to qa or a qa person comes in and tests your code there should be almost no barrier there they should be able to just look at the code look at the test case and say ah okay here's how i test it it's working it's not working where did it fail how can i go research it it should be all transparent there should be little or no back and forth between qa and development gotcha cool yeah i think so that's a good suggestion right with that i'd like to thank you guys for your time if you want to talk about any of these topics further or some other topics we haven't touched on yet send your comments and questions to us at info developer.com you can hit us on the contact us page on developernerd.com website you can search for us on youtube under developerner and we're also on vimeo.com developernerd our goal is making every developer better have a great day you
Transcript Segments
[Music]
okay our test bringing so let's go look
at the console there's our test
so we started spring boot
reset our data
we came in here the first thing we did
was a post
here's our api
we set the context to application json
as you can see here
our body contains the json object
our http response was actually 201
and the application came back was json
so if we look this guy should have
failed because i said 200
but we did get back the context
with our id of three
so then when we did our get we now have
three records returned so we see that
the first post worked
and the second post returned all three
however
the first one failed
because we did not get a 200 we actually
got a 201 so if i update this to 201
restart
and run our resistor demo again
and we see everything passed
that's because we received a 201 so we
got our 200 for our get a 201 for our
post
and our conditions passed now
all right so that's one and two
so now let's look at retrieving a
tutorial by id
and let's look at swagger real quick
so retrieving by id so we have to do a
get
tutorials by id
well we know we have one record out
there so let's try this guy out real
quick and just put one
and execute
so we have an id
a response should come back as 200
and we should return
a record and a response record should be
of type tutorial
and if you look here here is the url
that we need to
pass so let's look at how we set this up
so if we go over back to our code
so we have request we have base uri we
have get
so all this is the same with the
exception of our get so get
actually now requires an id
so we need to put in a token for id
and now we need to set the id value so
now we need to set a path param
and the parameter is going to be our
token there id
and
our value so in this case we want to
pass in one
just like we did over here so here's our
parameters
so we set our parameter
id
as one
and we added id to our get
so now this looks exactly like what we
have here in swagger
so now if i save this
and run again
we create the tutorial we retrieved all
tutorials and we retrieved a tutorial by
id so if i zoom up
the last call here
was to our get
so we passed in one
until we replaced our token
we got back at 200
application json
we set our path parameter id of 1
and we received back calculus so that
worked
so far so good pretty straightforward
all right so next we want to update by
id
and as you can see a lot of this is
pretty straightforward all you have to
do is follow some basic functionality of
how the apis are called
by id so we already have our id
so we've already defined our parameters
we've already set our api
however in this case we actually are
doing a put so if we go look over here
if we want to update we need to do a put
so put api tutorials id
requires the parameter id so all still
the same
this time though however we need to pass
in our body the tutorial value that we
want to update
and we're going to get back a response
again
for
the output
all right so here we have our given we
have our log
we have our base uri we have our
parameter
so there's two things we need to set
here so one
if we look back over here
we have to specify the application json
so in our
setup so we have base uri
we have
to set the context type
the application
based on
we've got that
we've got our path and now we need our
body
so to do the body we need to specify
some context so first we could do the
new like we did up here for the post
however i want to show you a different
way to do this so you can do this
another way so here instead of
setting the body you can actually set up
a json mapper
to do that you create a map collection
of a string
and object
and i'm showing you this in case you
don't have the pojo or don't have the
mapper
so if you do a json
as map
equals new
hash map
okay and then in here we're going to do
json
as a map
need to do that three times
because we need to set the
title description and published
so json map
we need to put
we need to put some information into our
collection
and now here we need to set our values
so we know we need title
we have our
description
and we have published
so if we don't have the pojo or we don't
have the entity being that we need to
build
this is a way for us to map it back so
if we go look
here and just look at this example
we see we have title description
published so we need to provide these
values here
in our put
so we see we have to have string string
and true
so we're going to come in title
string
some string
and this one will set to false
since we know calculus is already
published we will change it to something
else that's not published
so here i'm going to set our book title
to 2001
a space odyssey
and
again
a
another space
novel
and save
all right
so instead of doing the new
tutorial i'm actually defining our json
mapper now
to mimic
what we have to send in our header this
here
now we do not need to set id
because id is what we're actually going
to pass in as our lookup parameter to
set this value
all right so we have our log we have our
base uri we have our context type we're
setting our parameter
and now we need to set our body
to include our json mapper
is based on this map
including that
that looks good
and then we log and we should get 200.
so we'll save
rerun
and all of our test paths let's look at
our update here at the end
or report
so
we know one was calculus and math and
publish is true
we passed in
our body of description published in
true so this is our json map we
specified it as json and we set the path
parameter id as one so here's our put
and then what came back was id one
our new title our new description and
published as false
okay
that gives us four
now the rest of these are pretty
straightforward so i'm just going to
copy these down here and we're just
going to knock through them real quick
all right so we have five
five let's just simplify this for now
so five is find all published tutorials
and duplicate flagger
we want this one api tutorials published
there's no parameters there's no body
it's a straight up get
so we change this to a get
tutorials
published
we don't need body we don't need context
we just need the uri
and that should return to 200.
so that one's pretty straightforward and
that would be number five
okay save that
rerun
so that one ran and let's look at the
console
so as we see here we got back title
three four five and six all were
published true
now if we actually were to reset our
test we would only get back one of these
because we only had one hitchhiker's
guide to the galaxy
but it's interesting because we're
re-running this test continuously
against our in memory database it's just
going to keep stacking up these values
all right so now let's find a title
containing a string
so test 6
find by title containing string
and ironically enough
this is actually the first call we did
so if we actually go look back at
swagger
if we look we do not have a getter for
find
tutorials by string
if we look we have api tutorials
and if we expand that we see here that
we can pass in a optional title
so let's go back over here
so here we're going to need a
so we can kind of cheat we'll just go
back up here we'll need a path parameter
and this one will be type
and we want to look for
zero
i want to find the ones with 2001
and we just drop it back down to
tutorials
so our api we pass in the parameter
title
we just get api tutorials if you notice
we're not actually setting
anything here we're just setting the
path
parameters oops sorry wrong one yep so
not path parameters
this is actually a because this is a
path parameter this is actually a form
parameter so slightly different
so since this isn't a path but we need
to push this with the form
so this will be a form
parameter
now we call get api tutorials
so if i run this
refresh
and run our test again
everything passed if you notice we
created a tutorial we retrieved all
tutorials so we're just stacking up our
test so the last one here we were
looking for anything with a title of
zero
and since i restarted
our database
we got back one record you see here we
got back 2001 a space odyssey because
this is the only title with the zero
if you notice here if we go back one
since i restarted the microservice our
database reset and we only got back one
hitchhiker's guide to the galaxy
they're with me we're almost done
so next we want to delete
an individual tutorial and delete all
tutorials
so this will be delete a tutorial
and this is good for cleanup
so if you're running specific test data
and you have this option after you set
everything up you can go through and
delete everything and then validate that
your records were deleted
all right so again let's look at swagger
so we have two deletes here we have one
delete all one delete by id
we need to pass in a parameter for id
and we should get back a 200 that
everything was deleted
so
and this has to be a delete request so
instead of get we do delete
api tutorials by id
api tutorials
id
now this is not a form
perm path because we're updating the id
in the path
and this will be id
and
one
so delete
so we'll delete the first record
in the list and
actually let's delete
the second one
so we'll delete two
and
just test that we deleted this let's go
up and verify by id
yeah here we are retrieve the tutorial
by id so let's copy this guy
and add a second test to this one so
this will be 7
8
verify tutorial
was deleted
by id
and since we're doing two we'll follow
up with two
so it should return no record
so we should actually get back a 404
for no records found
and this delete will actually return us
a 204
all right so let's run this
this is running
our test is complete
it deleted our record and we verified it
was deleted so
the delete is right here so here's our
request
so we deleted we passed in the url the
api with our id of two
pathform id2
and we received back a 204.
and when we tried to validate it we
received a 404 because there was no
records found
okay and last but not least let's delete
all the records
and we're going to delete
all tutorials
and this will be nine
don't need
that
and our delete
should be back
and 204 double check our swagger
delete api tutorials
no parameters
and it should delete everything
all right so if i run this
everything work except delete a tutorial
that's because we actually
had already deleted number two
and therefore it's not there
so what we need to do for this
particular test is restart the database
restart the microservice for the api
with the database menu
once that's restarted then we can rerun
the test
and everything passed
so if we look at our last command here
we called our request
delete
api tutorials
everything deleted it returned back to
204
so now if we actually come over here to
swagger so i could write one more method
to double check this but what we can do
is we can go here to get api tutorials
click try out
hit execute
so it returned nothing
we have no body
alright so that is rest assured in a
nutshell so we walk through the
different types of commands here
so let's go back and just briefly go
over this
so we went through the different ways
you can use rest assured to
set up your request header
we define our base uri we can set
contact type we can pass in a body
either through a object
or
using a json mapper
we can post information
we can get information
we can use the path parameter id to set
an id on the url
we can validate the statuses of the
requests coming back using the status
code
we can also define our context type
within a request and within our response
we can also do
forms so we can pass form information if
it does not need to be in the url
and we went through using the delete and
verifying a delete
so are there any questions
so michael i know when it turns green
and that's when you know like the api
ran successfully
so um is there a way
like uh whereby you
you can let me say manipulate it and and
it turns green maybe
or
maybe you can throw in on a failure in
api because then anytime i run it
usually most of the time like
it comes out green all the time which
means it's uh
i mean i'm a tester because usually i
wouldn't know what goes on behind the
scenes so
these are all predefined tests
so depending upon your test data
if you're trying to test to make sure
everything returns correctly your
validation points in our case here the
status code
is going to be our assertion
so if you're unsure of what the test is
checking you can go look at the test and
then look at what is being asserted so
you could have an assert method here or
some type a status code within the rest
assured
with that being said though you really
want your test to always be green
because if it's not green then that
means that either a code change that was
deployed broke something
or the requirements that you're actually
testing against have changed and you
need to go update the test case or test
data to reflect the changes to the
requirements
okay okay
any other questions
not so much a question as much as just
sort of a
a statement i think to follow up with
these as we you know we've done a couple
of these now
the tools for testing
particularly at this level and it almost
it's funny so as i go through some of
these you know watch some of these
presentations is it's almost an itch to
build out proper testing
and i think it just points to it's
become such a
such an easy thing to do in many cases
when you include the tools you look at
the power of them and how easy it is to
just script out some tests
it to me it makes more sense than ever
for developers to
definitely be a part of it and be
building out some of their tests at
least their unit tests
and you know assisting qa more and
particularly when you look at like you
know sprints and
the scrum approach and things like that
where it's not
a you know sort of like a wall between
developers and qa but a partnership
um these kind of tools just make this
make that much more
easy to do and almost hard to argue
against it it's like you know how much
how much effort is it really going to
take other than thinking through some of
these tests
to build them out and particularly when
you're coding them in the first place
you almost those things almost fall into
place it's you know it's obviously test
driven development things like that make
that more uh push you to do that
but even if you're not taking that
approach it seems like you know testing
is almost a slam dunk at this point
exactly and it really should be because
even after i did all the presentations
on integrating testing in your
development cycle
really testing should be a no-brainer at
this point
i mean we've been in the coding now for
well over two decades and
this whole idea of
we need to separate qa from testing
really is a joke at this point
really if you want to write good code
especially in the microsoft world you
have to think from the end point so
basically you have to start with your
test what it is that you're trying to do
and then write your code for it because
if you do it the other way you're
really risking what is it that this
microservice is really going to do for
you
and the other way of thinking this way
is
as a developer
at the end when you're done writing your
code you know how to test your code you
know how it was tested now granted you
may make mistakes and what you write for
your test cases but as you get better at
this when you hand it off to qa or a qa
person comes in and tests your code
there should be almost no barrier there
they should be able to just look at the
code look at the test case and say ah
okay here's how i test it it's working
it's not working
where did it fail how can i go research
it it should be all transparent there
should be
little or no back and forth between qa
and development
gotcha cool yeah i think so that's a
good suggestion
right with that
i'd like to thank you guys for your time
if you want to talk about any of these
topics further or some other topics we
haven't touched on yet
send your comments and questions to us
at info developer.com you can hit us on
the contact us page on developernerd.com
website
you can search for us on youtube under
developerner and we're also on vimeo.com
developernerd
our goal is making every developer
better have a great day
you