Welcome to this new practical lesson about automated testing in January's framework.
Let's jump right into it.
It's very business with your code and as you can see I'm currently in the tests not by five of our profiles.
Application as you probably already know writing automated tests for your application is always a good
idea.
First of all as their name clearly states they allow you to check to test every single component of
your application in an automated way so that by running these automated tests you can be sure that everything
in your app is working as expected.
They also allow you to easily future proof your application because no matter the changes that you might
apply to your code base you will always be able to check if your application is behaving as intended
in the first place just by running these tests.
So let's make some examples of how we can easily integrate them in our Django framework projects.
First of all we need to import some classes and functions and we've got quite a few to import.
We don't need Django as test case class because Django framework provides us SPC chic API test case
classes.
So first of all import Jason.
Let's import Jangles user model from Django dot country.
Also that models import user and then the reverse function Django that you add else import reverse then
from a rest framework dose of token dot models import token from rest framework dot test.
And it is our API test case class up Dan from arrest framework import starters.
And then of course we need to import automotives and serialize us.
So from profiles stored models import profile and from profiles not API don't realize there's import
profile analyzer and they also give you a little extra TPA in cases like these where you've got several
import declarations if you want to check that everything is in proper alphabetical order.
You can use one of these ones to your codes of functionalities just right click and then sort imports.
And even though everything was already in order it added a couple of void spaces just to make a bit
more readable.
The first thing that we're now going to check is the registration End Point class registration test
case which extends API this case.
And here we can define a method def test and this core registration which accepts self is always.
And here we can define a data dictionary with all the data that we want to use to create a new user
instance.
So first of all of course we're going to need user name and we can just call it test case.
Now we're going to need an email.
We can set something like test at local host dot app then we're going to need password one which we
can set as some strong password and password to like.
So now we can use the client provided by API test case to make a post request to the registration end
point and check if everything is working as expected.
Pretty easy to do.
Response equals self doubt client and Dot post.
So first of all the endpoint and then the data that we want to send to be sure that everything worked
as expected.
We can now check the response status code and if the status quo is to or one created we know that everything
is working as expected.
So self not assert equal.
So first of all response dot status code and we want to compare it to status not should it be to a one
created.
We also actually need to add four words last year at the beginning.
We can now run our development server.
Let's open up another terminal and we can around Python management by test create and test database
for alias default.
And we see that everything worked just as expected we get an OK run one test in zero point one eight
five seconds.
We can now be sure that our registration endpoint is working as expected.
However we see this created through and created force which as you probably remember are called or rather
executed by your create profile function in the Signals stood by fights.
I'm going to comment this out like so.
And if we now run the test once again we see that the two created are no longer here.
One important thing to notice or to remind is that automated tests do not use their let's call it standard
database that you are using in development but is we can read they create a specific database that is
used exclusively in the context of testing your application.
And this is really awesome because most of the time you will want to war.
We have a database to test your application and therefore of course even a new one for free every time
you want to run your tests is great.
Let's now be the second Test Case class for this first part of the automated testing lesson and this
is going to be profile view set test case which of course is going to extend API test case considering
data and points provided by your profile view said class required us to be authenticated in order to
use them the first method that we want to create within our test case class is going to be set up and
we've been set up we're going to create a new user object instance.
That's what I've been going to use to authenticate ourselves but also to check our authentication is
actually working in the profiles app itself.
Def set up the self and here we can define self.
The user equals user not objects not create user.
And we need to pass first of all user name.
We can set something like that being cheap then we need the password so password equals some very strong
password.
We now need to create a token to use with the user so self-taught talking equals token dot objects that
create with user equals self-taught user.
Now to educate ourselves we need to define another method.
Def API authentication self.
And here we can set the self.
Not client without credentials.
And here we can pass age GDP authorization equals token space plus self not token and we can now call
API authentication from within set up so self not API authentication.
Now that's the setup of our class is completed we can test the deep profile at least end points.
And considering that we are going to reference the least you area several times you can just define
at least you URL as reverse of profile list.
And in case you're wondering we can go back to the API views that file right here.
And so you see the tag profile view set is defined query set as profile not objects at all.
Therefore the router Glasser knows that the list end point is to be called profile dash least which
is basically a standard.
Always remember that you can clear any doubts you might have by checking jingoist frameworks documentation
and the source code of classes and functions you're using.
So let's go back to the tests done by file right here.
Now going to define def test file list authenticated the screen to accept self.
And here we can define responsive as the self doubt client clients don't get itself least you Adele
and then your self.
Not us first equal response dot to code status not HDB 200.
Okay.
We can also define sort of up complementary method so desperate of a list and what's integrated.
And you're first of all we need to do to integrate our user and it is in fact pretty easy.
We can use the client once again self doubt client dot force authenticate with user equals none.
And this time of course we want to check for a difference that's good.
In this case 4 0 3 4 to be done we can now run our tests once again so I'm just going to clear test
to and we actually get an error you see which is a type error can only concatenate the string not talk
into string because in fact this is a self not token dot key we can launch the tests once again and
this time of course everything works fine which tells us that our profile at least end point is robust
and secure let us know test the detail endpoint so deaf test profile.
Detail.
Retrieve self.
And yet we can define.
Response equals self-taught.
Client don't get to but when to use a reverse of profile detail again for the same principles that we've
described here for a profile list.
But this time you also want to pass a keyword arguments dictionary with primary key one.
Basically want to get the details over our DaVinci user.
First of all we can check the status code like so but this time the stethoscope is not enough.
We also want to check if the details that we are getting back from the end point correspond to what
we might expect.
So for example self doubt assert equal response not data user.
Want to compare it to NAV e.g. which we know is the name of the user.
Let's now run the tests once again.
So the tests.
Everything fine.
Let's go check the update capabilities so let's check.
Def test profile update by owner self.
And now we can test if authenticated as DaVinci we are able to update the user profile information so
we can actually copy this one but this time the method is going to be booked and we need to pass quite
a lot more of data so seedy colonel and biography.
And yet we can said Renaissance genius self-taught assert equal we check the status code once again
like so and we want to check the whole Jason response so self not assert equal.
Jason got loads of response that s content and so here I.D. one user DaVinci but you're going to be
renaissance genius.
Then we can add the city like so
and I thought none.
We can also test what happens if a random users tries to update the same profile instance.
So I can just copy the code like so that this is going to be test profile update by random user.
So we do not need this code in here.
First of all random user equals user growth objects that create user with user name equals random and
password equals password.
One two three one two three one two three.
Which of course is to be a string.
Then we can use force authenticate
yeah it can just copy this line.
Like so do we use it equals random user.
And we could just try to update the biography with something like packed with three exclamation marks
and if everything works as expected we just want to return.
H TDB for all three four to be 10 which is therefore what we expect to get as a response so let's now
test everything once again.
Taught me no.
Like so
and everything works as expected.
Awesome.