WEBVTT 00:00.090 --> 00:04.860 Welcome to this new practical lesson about automated testing in January's framework. 00:04.860 --> 00:06.590 Let's jump right into it. 00:06.630 --> 00:12.670 It's very business with your code and as you can see I'm currently in the tests not by five of our profiles. 00:12.690 --> 00:18.630 Application as you probably already know writing automated tests for your application is always a good 00:18.630 --> 00:19.120 idea. 00:19.230 --> 00:25.440 First of all as their name clearly states they allow you to check to test every single component of 00:25.440 --> 00:31.590 your application in an automated way so that by running these automated tests you can be sure that everything 00:31.590 --> 00:33.800 in your app is working as expected. 00:33.810 --> 00:39.270 They also allow you to easily future proof your application because no matter the changes that you might 00:39.270 --> 00:45.600 apply to your code base you will always be able to check if your application is behaving as intended 00:45.600 --> 00:48.780 in the first place just by running these tests. 00:49.260 --> 00:54.150 So let's make some examples of how we can easily integrate them in our Django framework projects. 00:54.150 --> 00:58.650 First of all we need to import some classes and functions and we've got quite a few to import. 00:58.650 --> 01:04.950 We don't need Django as test case class because Django framework provides us SPC chic API test case 01:04.950 --> 01:05.460 classes. 01:05.820 --> 01:09.250 So first of all import Jason. 01:09.630 --> 01:15.010 Let's import Jangles user model from Django dot country. 01:15.100 --> 01:26.850 Also that models import user and then the reverse function Django that you add else import reverse then 01:27.210 --> 01:40.290 from a rest framework dose of token dot models import token from rest framework dot test. 01:40.380 --> 01:50.070 And it is our API test case class up Dan from arrest framework import starters. 01:50.250 --> 01:53.730 And then of course we need to import automotives and serialize us. 01:53.790 --> 02:04.370 So from profiles stored models import profile and from profiles not API don't realize there's import 02:04.380 --> 02:11.850 profile analyzer and they also give you a little extra TPA in cases like these where you've got several 02:11.910 --> 02:17.260 import declarations if you want to check that everything is in proper alphabetical order. 02:17.370 --> 02:24.870 You can use one of these ones to your codes of functionalities just right click and then sort imports. 02:24.960 --> 02:29.930 And even though everything was already in order it added a couple of void spaces just to make a bit 02:30.040 --> 02:30.930 more readable. 02:30.930 --> 02:38.910 The first thing that we're now going to check is the registration End Point class registration test 02:39.450 --> 02:44.150 case which extends API this case. 02:44.220 --> 02:54.450 And here we can define a method def test and this core registration which accepts self is always. 02:54.450 --> 03:01.770 And here we can define a data dictionary with all the data that we want to use to create a new user 03:01.770 --> 03:02.550 instance. 03:02.550 --> 03:09.830 So first of all of course we're going to need user name and we can just call it test case. 03:09.850 --> 03:11.850 Now we're going to need an email. 03:12.210 --> 03:20.850 We can set something like test at local host dot app then we're going to need password one which we 03:20.850 --> 03:30.970 can set as some strong password and password to like. 03:30.980 --> 03:40.300 So now we can use the client provided by API test case to make a post request to the registration end 03:40.330 --> 03:44.230 point and check if everything is working as expected. 03:44.230 --> 03:45.810 Pretty easy to do. 03:45.850 --> 03:51.760 Response equals self doubt client and Dot post. 03:51.760 --> 03:57.520 So first of all the endpoint and then the data that we want to send to be sure that everything worked 03:57.550 --> 03:58.360 as expected. 03:58.390 --> 04:05.050 We can now check the response status code and if the status quo is to or one created we know that everything 04:05.050 --> 04:06.550 is working as expected. 04:06.550 --> 04:10.530 So self not assert equal. 04:10.600 --> 04:20.350 So first of all response dot status code and we want to compare it to status not should it be to a one 04:20.740 --> 04:22.180 created. 04:22.180 --> 04:25.580 We also actually need to add four words last year at the beginning. 04:25.630 --> 04:27.940 We can now run our development server. 04:29.360 --> 04:36.850 Let's open up another terminal and we can around Python management by test create and test database 04:36.850 --> 04:38.190 for alias default. 04:38.320 --> 04:45.040 And we see that everything worked just as expected we get an OK run one test in zero point one eight 04:45.040 --> 04:46.120 five seconds. 04:46.120 --> 04:50.070 We can now be sure that our registration endpoint is working as expected. 04:50.230 --> 04:58.360 However we see this created through and created force which as you probably remember are called or rather 04:58.360 --> 05:02.390 executed by your create profile function in the Signals stood by fights. 05:02.410 --> 05:05.430 I'm going to comment this out like so. 05:05.540 --> 05:11.360 And if we now run the test once again we see that the two created are no longer here. 05:11.380 --> 05:17.620 One important thing to notice or to remind is that automated tests do not use their let's call it standard 05:17.620 --> 05:25.000 database that you are using in development but is we can read they create a specific database that is 05:25.000 --> 05:28.910 used exclusively in the context of testing your application. 05:29.020 --> 05:32.290 And this is really awesome because most of the time you will want to war. 05:32.300 --> 05:38.650 We have a database to test your application and therefore of course even a new one for free every time 05:38.650 --> 05:41.280 you want to run your tests is great. 05:41.300 --> 05:48.550 Let's now be the second Test Case class for this first part of the automated testing lesson and this 05:48.550 --> 05:59.980 is going to be profile view set test case which of course is going to extend API test case considering 05:59.980 --> 06:05.830 data and points provided by your profile view said class required us to be authenticated in order to 06:05.830 --> 06:12.130 use them the first method that we want to create within our test case class is going to be set up and 06:12.160 --> 06:15.430 we've been set up we're going to create a new user object instance. 06:15.520 --> 06:19.990 That's what I've been going to use to authenticate ourselves but also to check our authentication is 06:19.990 --> 06:23.020 actually working in the profiles app itself. 06:23.350 --> 06:28.720 Def set up the self and here we can define self. 06:28.730 --> 06:33.950 The user equals user not objects not create user. 06:34.110 --> 06:36.490 And we need to pass first of all user name. 06:36.730 --> 06:46.360 We can set something like that being cheap then we need the password so password equals some very strong 06:47.560 --> 06:48.940 password. 06:48.940 --> 06:58.920 We now need to create a token to use with the user so self-taught talking equals token dot objects that 06:58.910 --> 07:03.200 create with user equals self-taught user. 07:03.220 --> 07:06.610 Now to educate ourselves we need to define another method. 07:06.610 --> 07:11.000 Def API authentication self. 07:11.260 --> 07:12.690 And here we can set the self. 07:12.700 --> 07:16.220 Not client without credentials. 07:16.300 --> 07:28.480 And here we can pass age GDP authorization equals token space plus self not token and we can now call 07:29.080 --> 07:34.630 API authentication from within set up so self not API authentication. 07:34.630 --> 07:40.750 Now that's the setup of our class is completed we can test the deep profile at least end points. 07:40.780 --> 07:46.810 And considering that we are going to reference the least you area several times you can just define 07:46.860 --> 07:53.150 at least you URL as reverse of profile list. 07:53.470 --> 08:00.190 And in case you're wondering we can go back to the API views that file right here. 08:00.190 --> 08:06.790 And so you see the tag profile view set is defined query set as profile not objects at all. 08:06.790 --> 08:13.960 Therefore the router Glasser knows that the list end point is to be called profile dash least which 08:13.960 --> 08:15.340 is basically a standard. 08:15.640 --> 08:20.860 Always remember that you can clear any doubts you might have by checking jingoist frameworks documentation 08:21.040 --> 08:23.950 and the source code of classes and functions you're using. 08:23.950 --> 08:28.420 So let's go back to the tests done by file right here. 08:28.440 --> 08:37.690 Now going to define def test file list authenticated the screen to accept self. 08:37.690 --> 08:45.400 And here we can define responsive as the self doubt client clients don't get itself least you Adele 08:45.920 --> 08:46.930 and then your self. 08:46.950 --> 09:00.000 Not us first equal response dot to code status not HDB 200. 09:00.010 --> 09:00.790 Okay. 09:00.850 --> 09:09.500 We can also define sort of up complementary method so desperate of a list and what's integrated. 09:09.740 --> 09:14.400 And you're first of all we need to do to integrate our user and it is in fact pretty easy. 09:14.410 --> 09:24.580 We can use the client once again self doubt client dot force authenticate with user equals none. 09:24.640 --> 09:28.390 And this time of course we want to check for a difference that's good. 09:28.390 --> 09:37.070 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 09:37.180 --> 09:45.440 to and we actually get an error you see which is a type error can only concatenate the string not talk 09:45.440 --> 09:54.670 into string because in fact this is a self not token dot key we can launch the tests once again and 09:54.670 --> 09:59.860 this time of course everything works fine which tells us that our profile at least end point is robust 10:00.010 --> 10:09.240 and secure let us know test the detail endpoint so deaf test profile. 10:09.240 --> 10:10.510 Detail. 10:10.600 --> 10:13.510 Retrieve self. 10:13.510 --> 10:14.700 And yet we can define. 10:14.710 --> 10:17.670 Response equals self-taught. 10:17.730 --> 10:26.730 Client don't get to but when to use a reverse of profile detail again for the same principles that we've 10:26.740 --> 10:29.350 described here for a profile list. 10:29.950 --> 10:38.650 But this time you also want to pass a keyword arguments dictionary with primary key one. 10:38.740 --> 10:43.000 Basically want to get the details over our DaVinci user. 10:43.330 --> 10:50.610 First of all we can check the status code like so but this time the stethoscope is not enough. 10:50.880 --> 10:56.250 We also want to check if the details that we are getting back from the end point correspond to what 10:56.250 --> 10:57.480 we might expect. 10:57.600 --> 11:05.970 So for example self doubt assert equal response not data user. 11:06.120 --> 11:12.080 Want to compare it to NAV e.g. which we know is the name of the user. 11:12.150 --> 11:14.680 Let's now run the tests once again. 11:14.940 --> 11:16.660 So the tests. 11:18.370 --> 11:19.100 Everything fine. 11:19.600 --> 11:23.770 Let's go check the update capabilities so let's check. 11:23.830 --> 11:31.120 Def test profile update by owner self. 11:31.180 --> 11:38.650 And now we can test if authenticated as DaVinci we are able to update the user profile information so 11:38.650 --> 11:47.790 we can actually copy this one but this time the method is going to be booked and we need to pass quite 11:47.970 --> 11:56.970 a lot more of data so seedy colonel and biography. 11:57.000 --> 12:08.860 And yet we can said Renaissance genius self-taught assert equal we check the status code once again 12:10.920 --> 12:19.900 like so and we want to check the whole Jason response so self not assert equal. 12:20.080 --> 12:37.090 Jason got loads of response that s content and so here I.D. one user DaVinci but you're going to be 12:38.320 --> 12:41.610 renaissance genius. 12:42.520 --> 12:45.750 Then we can add the city like so 12:49.080 --> 12:53.350 and I thought none. 12:53.480 --> 12:59.120 We can also test what happens if a random users tries to update the same profile instance. 12:59.120 --> 13:08.300 So I can just copy the code like so that this is going to be test profile update by random user. 13:08.600 --> 13:13.540 So we do not need this code in here. 13:13.740 --> 13:25.800 First of all random user equals user growth objects that create user with user name equals random and 13:26.910 --> 13:29.640 password equals password. 13:29.640 --> 13:31.590 One two three one two three one two three. 13:31.830 --> 13:34.690 Which of course is to be a string. 13:34.980 --> 13:37.260 Then we can use force authenticate 13:40.140 --> 13:42.160 yeah it can just copy this line. 13:44.700 --> 13:48.560 Like so do we use it equals random user. 13:48.710 --> 13:57.690 And we could just try to update the biography with something like packed with three exclamation marks 13:57.870 --> 14:02.480 and if everything works as expected we just want to return. 14:03.070 --> 14:10.350 H TDB for all three four to be 10 which is therefore what we expect to get as a response so let's now 14:10.380 --> 14:12.240 test everything once again. 14:15.770 --> 14:16.920 Taught me no. 14:17.180 --> 14:17.880 Like so 14:20.770 --> 14:23.200 and everything works as expected. 14:23.200 --> 14:23.590 Awesome.