Automated Tests - Day 6 - Django Bootcamp

hello everyone welcome to day six ooh this is looking funny sorry about that well that's how it's gonna do okay so day six this uh slide presentation thing is gonna be incredibly s short i guess is the way to put it uh the reason being is because so much about testing which is what we'll talk about today has to do with actually getting into the code and doing testing and the reason you want to do testing is to maintain the integrity of what's going on here so testing i mean automated testing so obviously through the code when you run the code and you go into the admin and you do stuff like that that is certainly testing it's a form of testing but it's not automated tests or writing unit tests which is very very common um so just a recap of where we're at at this point we now can actually bring in a request and have a user logged in or not that request can carry data with it or not it's then handled by a django url the django url then decides where it needs to go as far as a view is concerned if it finds one of course and then it has a view that view might be handled by a form or some model and then a template's rendered obviously you could also render like json data but a template's rendered with the form and then you get a response back to the user so what tess will allow us to do is just really quickly write python manage.pi test and it will make sure that the patterns that we declare in these tests actually work right so if they don't work then we need to address it prior to actually going to the next step whatever that next step might be so let's actually jump into the code and actually see how this works okay so naturally speaking we're going to go into our project on vs code in our workspace here and i actually want to approach tests on accounts first so what i want to do here is actually do just general user accounts very first now oftentimes this is might be where you start it's actually doing all the authentication and all that the reason i didn't do that is because i want to actually work up to using users because it's kind of not i mean it's an incredibly important thing but it's not required to use users to get the rest of your application working but using test case are really important and what i'm also going to talk about is something called tdd which is test driven development and how that differs from the approach that we were going with um so let's go ahead and create our first class so this is going to be a test case class and these are very very common patterns as you'll see but the main thing is you often want to say what kind of test case it is so user test case now this is actually fairly arbitrary of a name just make sure that the actual test case class that's being imported into test.pi is there now i didn't mention that test.pi was also created when you did a start apps um call right so python manage.py start app and whatever that app name is inside of that scaffolding test.pie is certainly in there every single time so in if for some reason you don't have that scaffolding and you actually want to run tests calling it tests or tests underscore some name is a way you can do that so test underscore my test dot pi will also run um it's just a little bit different okay so it wouldn't doubt with naming the tests up high check out the documentation anyway so back to test.pi here what we want to do very first is called setup so define setup and notice that it is in camel case not in snake case i think this is because of python's built-in unit tests somebody please find that out but that's generally how we're going to be setting up this test so we're going to go ahead and say it passes itself and what i mean set up the test i mean this is where we'll want to create any sort of database entries now by default django doesn't actually have a database set up for a test right it will set up one for you based off of your database credentials so let's go into settings.pi here and i'm going to scroll down into the databases right so i'm using sqlite3 which for the vast majority of systems we already have permission to create and destroy tables in a sql light 3 file if you are using mysql or postgresql with password protection which i definitely recommend then you would actually need to set additional credentials for django to even create the test database now when i say test database it literally makes a new database every time you run a tests and then it destroys that database so we're going to go ahead and say user a equals to user so i need to grab in that user class itself so we're going to go ahead and do from django.contrib.off we're going to import that git user model as we do and i'll go ahead and say user equals to get user model okay so setup then means that i'm just going to be creating a user so go ahead and say username equals the cfe and email equals to cfe or whatever at invalid.com right okay so notice that i didn't actually save this user because i want to do a couple things with it i'll say user a dot is staff equals to true user a dot is super user equals to true and user a dot set password sum one two three password and then user a dot save okay so the reason i'm doing it this way is because in your form in your signup form perhaps you do something along these lines as well this is just essentially circumventing doing user.objects.create or user.objects.create underscore user okay so i'm essentially doing something very similar to that just giving some built-in features that django user models have okay so cool so this is the setup right so now what i've got here is if i activate this so source ben activate i can actually print out user a dot id okay so let's go ahead and do python manage py test and this is going to test my entire project so the nice thing about that is it can test the entire project or you can test a specific app so test.pi in this case is inside of my account stop hi or my accounts app and so i can actually call the app itself to test accounts right cool so let's make sure we save everything and run again and what we're seeing here is well i'm actually getting zero tests ran okay so the setup is one thing but what we want to do is also run an actual test so we're going to define test user exists okay so the naming convention here is also important you want to actually have it start with test underscore and then you can actually name it whatever you like otherwise and all this is going to do is say let's say user count equals to user.objects.all.count and we'll go ahead and use another built-in method called self dot assert equal and i'll explain this in just a second we'll go ahead and do user count and whatever number that we think that should be equal to okay so assert equal is built in to the test case and it's basically saying that hey you know it's almost like saying assert user count equals equals to one right that's very similar to that but this is actually running in the test case itself so you don't actually need to call a cert you would use the built-in one so another one is self.assert not equal and we could do that as well so user count is not equal to zero for example okay so now i'll also print out the user count and we'll run that test again okay so now this time it actually did print it out twice okay so there's actually a test in here which before there wasn't a test but a couple things came true number one the assert equal of user count being one is accurate right so this setup method actually did create everything i needed to create in that database and then down here i was able to actually reference what was created during that test session right so after i ran python manage.py test account it actually goes through this now hopefully right now you're like oh my gosh this is so boring right tests writing tests is incredibly boring um or at least that's how i feel about them that's why i actually don't cover them nearly as much as i really need to and also why i'm covering it now but it's it's all about in service of maintaining the integrity of your entire application as you can already imagine if something about this test case like if i was actually trying to create a user and for whatever reason that user was not created this very basic test would fail and maybe it's a permissions issue with your database maybe something in your settings change and you now have no permission to your database and this fails i mean right away it's like okay cool that is something that i need to do a lot more of and that's just a very simple thing just users failing let's go ahead and actually test a few other things like maybe the user password so we're going to go ahead and do define test user password right so i just want to verify that the user password i attempted to set here was crea correct um let's get rid of these print statements now and in fact let's actually make it incorrect first so we can see what that looks like so let's say for instance you were coding along and you're like hey i'm gonna actually save or set a user password this way so now i just want to verify what that user password is so i'm going to go ahead and do user query set equals to user.objects.filter and in this case username i exact equals to cfe it's literally this exact username up here oops we should put the username in a string okay first and foremost user exists equals to user qs dot exists and user qs dot count equals to one of course this is the same thing as this call right here so i actually don't need to verify this twice right it's really not necessary but if you were to do it you can just say self.assert true and user exists okay so there's another one a search true again it's just checking whether or not this is going to be true these are checking if the first item is equal to the second item this one first item is not equal to the second item right so not equal and equal right and then this is gonna say if it's a true or false value okay so of course that's gonna be true we just tested it right here and it came out okay so the password that we used well there's a couple ways on how i can approach this i can say user a pw is equal to this password and then i can say self dot user a pw equals to user a pw and actually pass it in like that right so now i can just come in here and say um that we get our user a equals to user qs.first and then use the built-in method called check password so we can just do self.assert true and this is user a dot check password that's a method that's built in to the user model itself to verify if this is the correct password okay so right off the bat i did a bunch of redundant things in here one of them being that i can actually set the user a so i can say self.user a equals to user a okay so the reason i'm showing you this is like yeah you can do a lot of things in these tests to make sure that you are doing actual proper tests but to make things really simple you can just do self.user a check password and self.user a pwe or pw so i don't actually need all of that stuff okay cool so we save that and now i'm gonna go ahead and run it again and we get two tests um and it's saying okay so what we've got here is set password actually did set this user's password um and it checked it just fine okay so what if we actually just called that password by itself such as a empty string here save that and now run it and again we're getting okay so what if i actually changed it again to something different we get failed now it's showing me that it ran two tests no surprise here we only had it two tests written but it's actually also showing me where it actually failed where the assertion error or where this self. assert true actually failed right so this is another one of those tests where you know maybe i actually don't need it per se but i i do want to make sure that that these methods are working correctly now in the case of django methods themselves we probably don't need to change them that often right so this assert password and all that stuff these methods should absolutely work but when in doubt test it just make sure it's ran in a unit test so whenever you run python manage.py test this is going to test all of the possible tests in your application and it will tell you whether or not something has failed and that's the point here we want to actually get it to a point where we want to test if something has failed so these are two fairly straightforward ones uh this is just doing a query set lookup right and then this is just doing a method lookup or a actual model method execution on the check password method okay so this check password could be something we used in our view and here right so i didn't actually run check password like i don't have a clean error so inside of forms.pi one of the other things that i could have done was actually run this clean method which um one of you got it well uh correct and it was just calling super.clean and then using this data and validation errors this was from uh i think yes uh day five uh but anyways so you could call the clean method in there you can actually grab the user object right so we could do that same lookup that i did have here you would be able to grab that user object check their password and if their password's incorrect in our forms validation we could run that validation error and hopefully what's going on here is actually making that hopefully clear maybe not but the idea is we now have a way to check passwords differently than we did with just simply the view where it was authenticate right so this is actually not checking the password in the sense that it's only looking at the password that was implemented whereas in the form we could actually get the actual user object and check the password in there cool so we've got a lot of tests to write so let's keep going the next test we're going to do is actually testing the login url okay so this is quite different right so what i'm doing here is i'm going to actually do a request to our login url so if you remember our login url in our case is just slash login okay so there is another place where this is located and probably a better place to test is actually based off of our configuration for our login url which is this right here this actually would be a good place to test or to at least verify that those are the same so let's go ahead and do that i'm going to go ahead and do from django.com we're going to import our settings here and we're going to just use the settings and i'm going to say self dot assert equal and this is our settings.login url with this login url that i'm testing now some of you might be like well why don't i just test that not use this login url yeah that's actually what we should do not not testing some arbitrary string that i just made but i'm trying to go off of what i would imagine your intuition might be when writing tests um honestly just going off of login url and just testing that because you know it off top of your head that's okay you know like tests are meant to help you in your development not meant to be this rigorous thing that forces you to spend more time on writing the tests than writing the rest of the application i absolutely do not agree that writing tests should take longer than writing the actual application uh some people don't agree with me on that but i do not think that's the case i think you should get your test done and then move on so that being said i am going to be using this settings.login url because i am very well aware of it so what that means is then i will just come in and say login url equals to that and we'll get rid of these okay and now what we're going to do is actually use a request client so if you're familiar with python requests it's pretty similar to that it's just a little bit different in the sense that it's just actually built into our test sessions and it essentially will help us emulate the development server it'll help us emulate the you know manage.pi run server so that means that we can call self.client and the method that we want to call so we can call get we can call post so those are the two methods we're really focusing on so we're going to go ahead and use post so it works like this we're going to go ahead and say response equals to self.client dot post and then it's going to be the url here and then our data dictionary and whether or not we want to follow any sort of redirects in our case with the login url especially we absolutely do want to follow those so again i'll go ahead and comment that out this is going to do our actual request itself so let's go ahead and write it out so first off the data for the form that we're actually going to be sending is username cfe and the password is going to be the same password that we had already created for this user right i could also put the username itself inside of uh self actually assign it to the test case itself uh but i don't you know it's not something i'm going to necessarily do right now so to test this we're now going to go ahead and say response equals to self.client.post and this login url with this data and then we're going to go ahead and say follow equals to true okay so there's a number of things that come in with this response so let's actually just type out dur of the response itself and we'll run this test now okay so opening the terminal up python managed py test and there we go okay so what this is showing me is all of the available methods and options on this response okay so i already know what i'm looking for but i think this is a good thing for you to go through if you're interested in how all of this works okay so first and foremost we want to actually get this status code and that is just response status code and then we also want to get the actual path or the where it's going to be redirect redirecting us to so redirect path and this is a post login only type redirect right so the actual redirect is coming from this login which we'll look at in a moment but it's specific to that specific view that's handling this specific url right um hopefully remember all those things but if not we'll take a look at that in a moment so to actually get this one we can use the response itself and then dot request dot get and there's something called path info in there again using the dur response you can actually see that here is the request um so you can call response on request and actually see what's in that request other than just this okay so there's a couple things that i want to have happen with this first off i want to say self.assert equal and that's going to be my redirect path and the reason i'm calling a redirect path is number one because of the url but also number two this follow equals to true means that it will actually be following what that redirect is uh so this redirect path should equal to you know my settings dot login redirect url remember that whole thing right here right so we actually want these two things being tested here and that's what's happening right so we're testing that and then finally i want to actually do self.assert equal and that's going to be my status code with 200. i want a 200 response finally as my response status code so this is going to be after the redirect after where we need it to go that hopefully will actually give me that status code okay so before we actually run this test let's actually see the view again to remember how all of this is working okay so first and foremost we have our form here so the data that i'm sending through on this test is this data right here notice that i did not have to write a csrf token at all that's because of this self.client so that's going to be posted to that login url and then in my view i actually grab the username and password no surprise that's the only data points that i have here and then i authenticate that user and assuming that this is correct it will actually log in that user itself now i would say yeah you should probably spend some time on if it's not correct like how to actually handle incorrect values as well but that's outside of what i'm doing here i just want to give you some of the underlying foundation to make all of this happen okay so then finally um after we run that uh the request itself and get a response back we check what that status code is of that final response including the redirect which in my case my redirect is actually a not well defined redirect and i'll explain that in a moment but then we've got our status code and what that redirect should be and that should be based off of settings notice that my actual tests is more resilient to changes than my views so in other words if i said abc here that is not actually where i want a post login redirect to be instead i want it to be coming from my settings okay and this is why we test things right so this is why we write these tests um let me actually re uh undo that and keep it n as that slash so we're gonna go ahead and save this and now we'll go ahead and test this out so again press up uh tests i'll just go ahead and do accounts and i get a failure right so assertion error login is not equal to slash okay uh so in this case i'm actually not getting a successful login no surprise there okay so the login url is possibly the reason for this so let's go ahead and see that we've got a redirect login redirect url yeah that should be actually redirecting us here so maybe there's like a little bit of a glitch as to what's going on with this request of course no matter how many tests you do sometimes these things happen right okay so um yeah that's all correct i'm not sure what's going on here i knew that it wasn't actually going to be successful so but that's not where it should be okay so let's say right here this redirect path is actually giving me the incorrect path itself uh we are going off of this login url so let's go ahead and just declare let's try just log in and see if that makes any difference and nope okay keep that in there and settings.log in url that is correct yeah so we're getting a funny response here that's a little odd okay so um i'll have to diagnose that soon but for now i'm just gonna go ahead and say assert equal and run in here with what that problem is so now i've got run tests and at the very least my status code is still 200 so i'm actually getting a successful response from this uh it certainly isn't redirecting for some reason like i said i'll have to i'll have to figure out why that's happening but this this is a good example of when you write tests things happen where you're definitely going to need to solve whatever that problem is you know perhaps the user authentication is incorrect you know perhaps i actually put the wrong data down here so let's go ahead and actually look at so we've got the correct username we've got the correct password um so all of this should should be coming through here so password username and at the very least it's uh rendering out the correct url um once again i can actually print out response dot request let's actually take a look at what's coming in this response.request and yeah it's still giving me the login url okay so not sure why that's happening sorry about that just a simple little error but one of those other reasons why we run tests i'm actually just going to copy and paste my local testing when i was running this and see if maybe that one does it and i don't think that's the correct password so let's go ahead and grab that one okay let's try it again yeah that's strange okay so not exactly sure why that's happening that totally should do the redirect based off of this oh i know exactly what it is okay so here it is so see this login url we go into our urls.hi so i've got my login url here but in settings.pi notice this login url is not having a trailing slash i believe this is probably the problem and what's happening is this is trying to actually redirect me to the one with the trailing slash and i think that might actually solve the problem it also might not so let's give it a shot and no it does not solve the problem i don't believe it does at least wait let's see here let me comment out one of these there we go let's try it again yes no it still did not solve the problem okay so that doesn't solve the problem but in theory it actually does um i'll have to go back and figure out why perhaps you guys can look at this and say like hey you did this part wrong but the main thing here is number one we can actually do a request here it should actually take me to that user's login uh whatever that ends up being which in my case is just the login url so strange uh and then we can pass in some data and we can test and make sure that that's done okay so naturally that wasn't the only tests that i actually want to run um so hopefully i'll get that solved and put it on the github repo later so let's go ahead and into our products now so products.tests this is another place that we're of course going to want to do some tests on and in my case it's actually pretty simple it's going to be based off of this staff member required here so what i want to do is actually create a super user and a non-super user or well a staff user and a non-staff user to see if they can actually access this url with some sort of data okay so inside of this now we're going to go ahead and run in again we're going to go ahead and do from django.contrib to off we're going to import the get user model here and then we'll go ahead and import from the models we're going to import product okay so user equals to get user model and we'll go ahead and do class product test case and this takes in a test case here and we'll go ahead and define setup we'll do self and we'll say user a equals to user and again i'm actually going to copy the same exact setup almost as what we did in accounts so again copy just the setup portion here copy that and bring it down here okay so we've got user a in here with uh the super user status and staff status well we can also just call it um we don't need it to be super user status it can just be staff status as in they are a staff user and therefore they should be able to actually view this url here so going back into that test we want to create another user so i'll just call it user b equals to the user.objects.create user and it's going to be user 2 and then cfe3 at invalid.com and then some one two three password okay so i've now created two users let's go ahead and say self.userb equals to user b create two users here so let's go ahead and test the user count and again i'll go ahead and say user account equals to user.objects.all count and assert equal user count being three right so this is intuition we created one two here but we also created one here right so i created three users total right so this should be successful let's go ahead and run it so python manage.py test we can run the whole thing and hopefully wha what's going on here user count two is not equal to three so i'm saying three here but this is coming back as two well all that's doing is it's actually keeping this entire test itself self-contained as in what's happening in this test doesn't matter with the other test so users being created all that doesn't matter so we actually want to test the user account based off of the setup process that's happening here so simple as that and just something to keep in mind the other thing is every once in a while you're going to be like oh inside of one of these tests i want to add something to the database don't do it in the test when in doubt put it in the setup process and also when in doubt if you're like oh my test is really really big just go ahead and say class product use case test best case and just make literally another test case that keeps your tests hopefully fairly fairly small obviously they're not too big you don't necessarily need to have a bunch of tests in here but really if you're running a setup process that a lot of tests can use then yeah make a bunch of tests but if you have a setup process that each test is doing something different with then then you should break it out into different classes right so if you had three different users in here for three different tests specifically break it out but in my case it actually makes sense to have these two users because of what we want to test now which is test invalid request and that takes in self and what we're going to do here is we're going to just test that this user is invalid okay so first off we do self.client.login so this is actually how you can log in your user so username equals to self.userb and password equals to we're going to pass in that username password so this is how you can actually log in through to the test client itself so this is giving me a logged in session for this particular user and now i can go ahead and say response equals to self.client.post and what i'm trying to test here is whether or not this user can actually create a product so i i post it to the products create and then i add a title and this is an invalid test hopefully or well it's actually a valid test but invalid permissions right so let's maybe call it a valid test um and now what we want to see is self dot assert uh true that response.status code is not equal to 200 or 201. i think we actually return back a 200 uh response with this although it probably should be a 201 okay so we let's go ahead and test that now we run this test and we got all clear right so if i wanted to say that this response is correct what i basically i just want to make sure that this user can't do that so to verify that this actual products create is sending back a 200 response if we actually look at the view itself this render is always going to be 200 right so i didn't actually change the status code at all uh if you were using a class based view it would use a different status code that's a little bit of a bug that i have in there but it's okay for what we've got here so there we go so we now see that this is an invalid um response so what i want to do is actually the exact same thing and now we're going to use user a and i think we have the same password for both of them so it doesn't really matter how we write that out so user a there we go and this time i want it to be equal to 200 so i did a self-assert true so another one is assert not equal which is actually what we probably should have used so response status code and 200 and then now assert equal status code and 200 okay so user a should have a valid request because of this flag here for staff we saved it all that this one didn't did not have that flag at all the first one worked fine let's go ahead and try the second one and what we should get is ah we get a error here so what we're getting is the error let's just check something real quick so we got user a username and perhaps it's this set password order let's rephrase that here okay so we try that again and there we go so what happened set password didn't actually work or didn't fail before but it failed this time so what's happening here is we just want to make sure that when we are creating our users we don't want to do too many steps at all but then also when in doubt you want to save the user model when you do set a password so in other words let's go ahead and say user a dot save here and we'll try that order run that again and this time it should actually work and it does right so unfortunately the shortcomings of tests every once in a while is this right here so i actually just checked that actual password but part of the reason that it's not invalid is because this is actually not looking in the database itself so this also brings up oh that is a poor test altogether and i almost had a good test so coming back to this right so this would be your intuition and what we just tested in a different test is now like okay we clearly need to change how we were doing that test so we'll go ahead and say user a equals to objects or user.objects.get and now i'm actually looking up this user not actually referencing what's on the class or what's attached to the class i'm actually looking up the user in the test database and now this is now user a going based off of that check password and now when we run this yet again what we're going to see is an error so too many values to unpack well i ran six tests um so let's see here test user password yeah so clearly it's not working right so let's just move that back up into saving it into the database and we run this and um now we're getting a 404 error ah okay so this is now on our test login url interesting okay so this status code is giving us a 404. now it's actually working okay so um i realized why it's actually working so number one this is a poorly written view for several reasons one this right here is not actually giving us the correct response that we need we wanted better form validation in here which is yet another reason to write tests and this is why it all hinged on this poorly written user create and this poorly written test user password that is actually why this was happening um very silly error but yet another reason to show you tests in real time so in other words now if i actually change this by saying assert equal this this will also give me the invalid error and we see this 404 page i'll explain that in a moment but if we run this now we've run this test again it's running all of those tests a couple things are going to be um you know we only have one error here one failure here that is giving us an error two but let's go ahead and actually i'm going to comment this out real quick before we move forward and let's go ahead and run it again i should get success now but if i'm not then i'm getting a problem oh yeah this is another problem silly silly silly silly okay so there we go so now we're actually doing a proper lookup um so there it is that's successful that's great let's go back into our url here and save it run it and now we still get that same error but this time it's saying 404 is not equal to 200. right so if i change that the the password that we're passing this will also illustrate that my view itself was poorly written and giving me that same assertion error of the actual request itself literally the same one that we saw before so we bring back that same password let's come in here and run it again and the reason we're seeing this 404 page has to do with where it's being redirected to right so it's giving us a 404 status which means page not found that's an http status that's worth looking up uh but that is because inside of our urls we now see this that we don't actually handle the base url right so it's not in there anywhere so let's just go ahead and put our search view as that url so i'll just go ahead and do path with an empty string that's our search view so now it's a home page because going back into that view itself or views.pi again it's redirecting to that home page right there although that should be based off of the settings module itself but now that we've got that we're going back to all of the tests and still getting a nun type this is a different error this is based off of our view of course off of our view um okay so yet another another reason to actually be writing tests so i'm actually going to show you just a really simple url that we can use so from django django.generics or rather.views.generics we're going to import the template view hopefully that's the correct import if i remember correctly so we'll go ahead and say as view and template name equals to base html okay so that's a very simple way to actually just render out a template uh so we're gonna go ahead and run this again and wait maybe it's django dot generics views now that i think that's wrong too let me just do a google search and there we go so that's what happens when you do these things live so django uh template view okay and [Music] generic ah generic it's just generic not generics i'm confusing it i think with the django rest framework okay so there we go so views.generic and there it is okay so now everything's successful okay so so fun writing tests huh okay so there is one more thing that i want to mention which was test driven development so which test driven demo development is telling us is instead of actually writing models or views or urls or anything like that what we do instead is we're going to go ahead and come in here and say clear we'll run python manage.py start app orders and inside of orders what i want to do is actually start writing my tests so i'm gonna go and say class order test case takes in test case and then we define setup and we'll probably need users for this yet again right so just just like we did with the products themselves so let's bring in the user model or the user test rather so i'm just going to copy and paste this one for user a we just need a single user in fact i'll copy this entire top portion here so let's go back down to this and bring it in here and simple simple stuff okay cool so what test driven development would do then is test create order and this would say basically well we would use obj equals to order dot objects dot create user equals to self.user a and then product equals to product a or something along those lines so test driven development would say hey create the test first before you even have the model run the test and then create the test or create the model based off of the test that you that you wrote okay so then you're sort of coding to the test and making sure that common testing is done throughout um so yeah that's uh that's how we actually would run through and do our testing with tester driven development naturally in my case i am not going to do that at this point but i just wanted to mention how it's done uh just so you're aware so essentially you would be this line right here it's perfect line now okay well now i know that i need a user and a product on this order so i'd come back in here and then say class order and then have you know user and product on here now intuitively we would already know this but the the main thing is that that is how you would approach tested and driven development you do all your tests first then create the models to it okay cool so a few hiccups there i apologize for that but we did cover quite a bit on doing tests and illustrated why they can be so important right so even myself i've been doing this a long time every once in a while you make mistakes and writing tests really help signify those mistakes so if i were to write this user test for example and then six months later or two months later a week later i went to write the product test and did roughly the same thing or attempted to do the same thing with now logging in and all that it highlighted how poorly written that original test was right so this right here was a poorly written test even though it didn't seem like it should be right so part of it was i wasn't actually doing a lookup from the database right part of it was the order of how i was actually assigning things to the user model itself now you're not always going to have these kinds of problems or this specific problem and honestly i didn't recall what it was because of course we're live i didn't recall that that ordering was the reason for it it was just something i overlooked but again that highlights what's wrong or what tests prove with what's wrong with code from time to time the other thing is if i now sent you this and you ran python manage.py test you can now see all of the different tests that are happening and hopefully you're getting this successful call here so that's the other part is now that there are tests in here you can actually as a developer come into the tests and see just generally speaking what i am trying to do with this code naturally there's other things that i would want to test which is the register url that's absolutely something i would want to test the other thing is inside of my views the or rather the products themselves i only tested whether or not a staff user can look and create these products rather so i didn't test if you can actually get those products based off of their their ids or how i actually set up the url patterns themselves i didn't test any of those things and that's certainly something that you would also want to test but as you can see tests are a bit tedious not that much fun but are incredibly important okay so i'm going to go ahead and answer some questions now let me just load this thing up uh thank you for watching if you stuck with it this whole time especially through all of the little hiccups that happens when you go live you know what i mean yeah okay so um if you guys have any questions please let me know in the um in the comments below i'm happy to answer questions um just give me a second while i pull them up on the screen here i just need to refresh my session a little bit and it looks like we i might be able to actually go through a lot of the other questions because tests are definitely not a super clickable subject in my experience uh okay so let's go ahead and start off i'm probably not going to go through all of them but i'll just go ahead and say hello to some of you thanks for coming out um the podcast yeah so i just did a podcast interview uh so if you actually go to my uh twitter at the very top there i did one with uh matt from justjango um really fun interview i had a had a good time chatting with him uh it's gonna be interesting to see where his podcast goes and as well as all the other things that he's doing um so check that out the link is on there so thank you for that question that's certainly something i wanted to address early on um abraham thanks for coming out i'm glad you were eager to get started i was as well um emmett hey what's up i love that you call me maester like i'm maester ayman huh just kidding django tested driven development is a first for me yeah i don't love doing testing room development i know that some developers swear by it um and i can see the value in it in the sense that you're creating these tests first and then you start developing the views the models everything i just i just have a hard time really appreciating it with other people because myself i like actually building the real thing first and then checking for cracks after um that's that's just always been my way of doing things with django it's really hard to be like oh let's let's anticipate cracks happening so we'll make tests for them you know what i mean uh so anyways thanks for that how can you test uploading um so there's there's a number of ways on how you can actually go about testing the uploading process uh self.client in a test case itself that's how you would potentially do that uh so thanks for that one uh testing the django rest framework um this is actually something i cover in rests api course on my website it's actually not a whole lot different than what we did here if i remember correctly the django rest framework i don't remember if it actually uses a different client or the same django client i think it actually uses the same django client you just have to use additional headers to it it's actually really not that hard or you could just use session authentication for the tests themselves for a variety of things there too thanks for the question okay so it looks like um uh vinjay i think you were pointing out the the problem that i was having um with the original test case that i think i ended up solving uh good catch if you did why am i using test case it's built into django it's a lot easier to just get going for the vast majority of people that's why one of those batteries included things here good question using fixtures will simplify the test data absolutely i haven't covered fixtures yet in the django bootcamp i'm not sure i will but for everyone else basically what you can do is you can serialize your data into what's called a fixture so it's basically a bunch of json data that your test itself can actually load in to the test instead of actually writing out the data like i did or writing out the development process like i did because you know i i set up the users the single user model a few times um using just a json file and loading that in whenever i needed those users that would absolutely simplify writing the test data so i appreciate you saying that um yeah thank you for the nice comment um yeah i'm not sure if today showed showed what i'm good at um i i totally tested all of this stuff several times because you know whenever you're live there's gonna be hiccups i i know this really well um because normally like if i'm creating a course or something like that and it's just not working i just stop for like 20 minutes diagnose what's going on go back and just alert you to what what potentially could happen as the problem um so that sort of recap once i actually did find the error would have would have happened much sooner if i wasn't doing it live you know what i mean um so live good and bad i guess the good part is i can actually address it and answer your questions right now so especially for those of you who have showed up hey i'm doing well thank you how are you and let's see here can a django beginner cope uh catch up with this project boot camp yeah i mean if you start on day one i think you should um you could be able to learn a good amount of things uh through it um but i mean like i think a lot of you can see right now tests are just not fun like there's there's not nearly as many of you today as there were um in the first five days and because like who wants to click on watching automated tests that's so boring but it is important i do get this question asked a number of times and it's like well a big part of the reason i shy away from doing this because we are testing the code while we're building and we're just not using automated tests so yeah um here's one you got totally lost yeah so i think i think i started going into software developer mode when the tests failed and perhaps i didn't articulate it very well so i apologize but thank you for staying with me um that's why i'm hanging out here too now is to answer questions so if you guys still have questions let me know happy to answer them um and i'll stick around for a little bit longer too just to make sure we can get this done so python anywhere heroku i think heroku is really really easy so i haven't actually used python anywhere very much but i do enjoy using heroku for a lot of really quick development for projects and all that uh so good question so i did mention this but maybe i didn't clarify too much so on your test case let's go ahead and take a look for that one [Applause] so right here follow equals to true what this will do is actually follow the redirect that may happen in the login url itself right so in the login url we actually run this redirect method here actually that's a register method um but this login this will redirect so follow means that it's just going to stay with the view until it actually redirects right so not everything's going to do that of course so you don't always need to follow it but you know if you're in doubt of it you can just go ahead and follow it it's a good question hopefully that clarifies it the documentation for that on django is not incredibly clear either is this tutorial for beginners uh that was the goal but i think there's a few hiccups in it that make it maybe a little challenging for beginners but if you watch it a couple times maybe that will really help especially the parts where you're really struggling but early on ideally you've done day one of the django boot camp up until today so you would be able to at least fully understand everything prior to jumping in to doing the proper tests so thanks for the question i want to create a different login for admin and user how you can do it uh just a different view so if you want a you just create a different view with a different form that's pretty straightforward i think to do thanks for the question uh let's see here how long will it take to learn django to start making basic websites honestly i think from day one to five of the django boot camp it gives you enough to to make basic basic websites um now it's just about uh improving that i think so somebody else could chime in there because i i think that but i've been doing this a long time so maybe maybe that's why um yeah so documentation reference to look back um yeah so django's documentation for django tests is absolutely something i would recommend that you look at because it will cover this a lot and it does it very very well so yeah thank you next one you were the one who solved the password question from the last one good job sega yes you were the one that's right i knew it was you i mentioned to call you out um but uh i didn't i didn't have time when i was actually setting up the um the live stream today to actually do this but thank you for for the correct answer that was awesome nice work there yeah uh okay test driven development isn't always good when using coverage uh yeah that's good points thanks for sharing another good point about test driven development um okay so let me see here trying to get all of the the new questions this q a thing uh that i've been working on does work well sometimes but there's still a number of glitches with it that i'm still trying to work out um here's a good question so what's the remaining topics for the remaining days um so naturally we need to allow a user to actually order anything right so to actually perform an order of a product measure those things perhaps something related to inventory and then ideally having some some like email confirmation and stuff like that at the very least that also probably means that we need some static files in there as well so that's a few things that we will be covering um at that at that point okay um so question here how long did it take me to get this good at django i mean the way you were debugging is so impressive um thank you for saying that i shouldn't have had to debug to be honest with you i should have caught it much much sooner um uh how long i've been doing it i don't know if is incredibly relevant to how well i can debug things um debugging is a matter of actually practicing a lot and breaking things a lot and and trying different implementations of the exact same thing right um so like if i was if i was just building generic views all the time generic tests and not really pushing the bounds of of how to do things then i don't think i would actually be able to do much debugging um so this this actually comes with building a lot more projects and giving yourself like a very narrow scope to execute those projects right like like really really these these this boot camp is meant to not have me debugging things but to have those things already debugged so so to me that was like a hiccup that was probably worth seeing yourself because you can see like someday you'll be able to debug things that that quickly maybe maybe even faster than that you know what i mean um so yeah but i've been actually doing django for almost uh nine years now here's one don't be upset i'm not upset um it was just kind of a bummer you know like that doesn't mean i'm like worked up about it it's just like like when you do these live things and you practice it especially for me like i practiced it i was like ah yes like i totally got this down i'm ready to go but i practiced that yesterday right so if i did it this morning prior to it then it would be fresh in my mind i'd be able to easily knock it out um but every once in a while that's what happens when you go live and yeah but thank you for the super chat and for that message i appreciate it appreciate your support i was absolute zero and django following you since day one of boot camp and i'm getting everything that is awesome that is so cool to hear um so this is like i mean if you guys are in the same camp please let me know because when when you when you get to a certain level with any skill it's it's really hard to remember all of the challenges that you go through as a beginner right i think i do a decent job when it comes to django for that mainly because of the questions and the responses i'm getting from you guys like hey i don't understand this right so when i hear that a number of times then it's like well clearly i'm like jumping over something that should be discussed more in detail prior to going any further but uh thank you uh vinjay i appreciate it for mentioning that and hopefully you are getting a lot out of this uh here's one we need a password page setup tutorial uh so i'm assuming you mean like password reset check out django all auth for that it's incredibly easy to do i think i think i have a tutorial somewhere on doing custom auth with the actual passwords and all that it might even be in my e-commerce course on my website i don't remember for sure but um thanks for that we need all errors fixed tutorial like how to fix basic error yeah i mean if if you have if you have a lot of errors all the time um it's it's a good way to really test your skills i think right so one second errors like errors occur when you're doing new things to yourself and that's a really good time to learn i think right excuse me just one second oh sorry guys i um had a cough pretty good pretty good there i think talking talking and looking this direction is like what causes what causes that um but what i'm saying is you need something related to errors absolutely so um the more you do projects the more errors you're gonna have so like me making a tutorial of how to solve common errors i think might be a good idea um so yeah thank you for that question that might be a that's a good recommendation thanks python debugger and django debugging would be cool as well yeah so the uh jango excuse me the django debug toolbar is incredible um for debugging things as well as making more efficient database queries so yeah thanks for the question um no not at all just i'm looking funny silly um so here's a good good one need advanced registration with a secured user no one can hack um so to say no one can hack something is probably not possible anymore right especially with machine learning and deep learning those like prove you're not a robot things well robots are starting to prove that they can solve those so yeah i would look at least into recaptcha into registration forms that that is something worth implementing um but it's outside the scope uh for beginners thanks for the question though thank you thank you thank you so much glad you enjoyed this hello welcome hello thank you deletes migration plays it phrase it works um yeah i mean when in doubt delete your migrations and your database especially in development in production you probably don't want to do that but you know in development you do okay so um if we don't have any more questions that are related to what we did today um let me i think i'm gonna just be jumping off but uh thank you guys for coming out and watching this one um how do you implement a user model i'm assuming you mean a custom user model because django has them implemented by default um i definitely have something on my website for custom django user models it's pretty pretty simple to do and my website is here so cfe.sh right there um so check that out yes okay so do you guys have any more questions about um tests let me know you just joined you'll be definitely watching day one good that's that's great to hear trevor that is where you should start i think um absolutely so yeah thanks for thanks for coming out and joining um hey look at that my aws tutorial saved your life oh thank you i'm curious as to which aws tutorial because i have quite a few of them but thank you for the super chat appreciate it and um i have this now um i i heard that some people around the world don't have access to super chats so here's a paypal thing i guess you can scan it with your phone if you ever want to drop a tip i feel kind of weird like putting that up there but somebody was asking me about it so there it is and it's gone it's just so weird because i'm not i mean these boot camps are made to help you guys as much as possible right um and sure i would love for all of you to become members on codingfrienders.com which is cfv.sh right i would love for you all to become members on there uh but what i'd also love is that you actually accomplish the things that you're setting out to accomplish in the world of software and you're able to help other people move forward in that realm as well software i think is too important for only a few of us to be doing and i also wanted to demystify the um the challenges it is when building pretty robust applications um so yeah i don't know and hey large aws file uploads great um have you actually seen i i noticed that you just said you remember i love it um i actually saw that you have um so that means that you definitely have access to the dive into aws course um that thing might help you a lot with all sorts of aws related things as well on cfe dot sh courses um if you're interested in that um more because because the i don't know where you got the large file uploads part maybe it was from that course but um there's there's just there's just a number of things about aws that continue to get more and more complex that like just that course alone just kind of cuts through all the noise and hopefully gets you directly where you need to be with python and django projects so yeah [Music] and next one do i remember you from my comment on titan ai you watched my 12-hour course on reaction django and created handshake i do recall that i don't necessarily recall what handshake was all about um right off the top my head right now but thanks for coming out and saying hi appreciate it uh it does mean a lot and oh this is a good question how to debug a synchronous code uh you don't no i'm just kidding um there is a number of documentation i would i would take a look at python's asynchronous testing documentation um or i believe aio http has a number of ways that they implemented tests um i'm not sure if django has the asynchronous tests built in yet but honestly on the client side the client side um well actually it really depends on what your asynchronous view or asynchronous code is doing to really fully test these things out but there are a lot of different documentation on how to actually go about about doing that it's it's not incredibly different than what i just did um but django itself i i haven't spent much time doing the asynchronous django debugging or actually writing tests for it um yeah so you asked how to debug it um not how to test it so one of the ways you could consider with your debugging is actually turn it all into synchronous code initially like write it out as synchronous code and see if there's any bugs or errors in just the synchronous code so it's blocking and you can see those errors in real time another way to do that is to actually remove asynchronous features and this is totally like not relevant to today but thank you for asking uh the question because the reason it's not relevant today is because we just didn't do anything um you know related to asynchronous code today so yeah cool awesome great to hear it yeah so the these uh these comments i really need something that's related to if you're a member on j uh codingfriends.com uh because that's definitely something i need i want to highlight more of but it just adds a bunch of integration things that even even now the way it works is still a bit glitchy would i recommend developing a booking reservation system from scratch or use a third party now this is a good question that's not relevant to today but it's it's relevant to the bootcamp in the sense like do i do i build it from scratch or do i use a third-party application um well if it's for learning always build it from scratch right if you need it implemented for work third-party things are fantastic to get it done right away while also trying to learn how the third party actually executed what they did right so you can learn a lot from that a good example of this is like if you were building an e-commerce application um from scratch which yeah i think it's awesome to do and you'll learn a lot what you know who are you going to model it after are you going to just you know pick out the sky and try and do it or you can actually use a model not like a third-party model right so amazon would be a good model probably maybe not because they have millions of products apple might be a better model because they don't have millions of products they only have a few um and then maybe places like um oh geez i'm forgetting what the name of the company is but cam link the the people that make uh how i actually record this from my dslr uh they make something called camling 4k to take a look at their website they don't have that many products but um it could give you an idea of how you need to situate your own e-commerce now i don't think that's any different from for a booking reservation system you want to see how others do it first and really just think about what's driving any aspect of that application right so if it's happening asynchronously kind of like a like button how does a like button work you know stuff like that um hopefully it answers your question okay cool um yeah so that's probably gonna be it i don't know if there's very many other questions that are relevant to today [Music] and the things that we just talked about looks like i'm not getting all the questions give me one second um are unit tests more important than functional tests um well i think what's important is that you start thinking about writing tests i don't know if how you write those tests is incredibly important at this stage for the vast majority of you i think it's more that you want to just get in the habit of like okay i just completed a feature now i'm going to go ahead and create a test for it right create another feature now i'm going to go ahead and create a test for it um so do that as best you can but not get too nitty-gritty into some of the challenges that could come up with with writing tests like you don't want to spend hours and hours and hours writing tests um you just want to be like okay i just made this view let me just make a quick way to test it oh i just made this model i'm going to write a quick test to verify uh the integrity of that model that um anything related to that model is actually working as i intend i think that's what's most important when it comes to writing tests initially as a beginner another thing that you can start thinking about is something called an end-to-end test where it's like literally testing how your entire application wants to work i think that is actually what you really want to work towards is having a pretty solid intent test that takes into account different kinds of users and you know that whole request response cycle that i mentioned before uh that would be another thing that would be worth trying out um but i mean it it that would take a good amount of time to write an end-to-end test for any django project um so yeah thanks for that one hey no worries thank you for saying sorry it's not it's not that big of a deal i yeah as you guys probably know i go on tangents a lot myself so answering tangent tangential but the right way put it uh tangential questions is okay too um yeah uh ranotex i actually haven't used rhino rex testing um so it's a good question um gui tests or front-end tests um you could use something like selenium it just starts to get a little bit more complicated you know i mean because i'm not trying to make this incredibly complicated i'm just trying to get you guys aware of how to do at least basic testing because it's often overlooked by myself and other other um other teachers out there because it's it's just so mundane to write tests some people love it but i just don't you know what i mean um ranorex is gui best oh interesting i'll have to check that out okay so um thank you for all of the questions thanks for coming out today um tomorrow we're gonna be doing some more stuff so hopefully by friday we will have finished the first iteration of the django boot camp so make sure that you come out and same time tomorrow as it was today uh but yeah thanks again for asking all of the questions and checking out tests see you guys next time

Channel: CodingEntrepreneurs

Views: 12,662

Keywords: django, django-bootcamp, ecommerce, django3.1, python 3, web application development, python web apps, djangocfebootcamp2020oc, live coding, live stream

Id: 5E_xLmQXOZg

Length: 80min 2sec (4802 seconds)

Published: Mon Oct 12 2020