Django automated testing with GitHub Actions

hello and welcome back to another tutorial okay so this one we're going to be looking at github actions well in fact i'm going to take you through a whole process here of setting up github so this is phase one two and three we're gonna set up github with django uh do a little bit of testing cover uh coverage again and what it does and have a little look at styling conventions pep 8 for example and have a look at the flake package so we're going to go through those steps and then we're going to then move on to github actions in step four now by all means if you don't wanna go through setting up github and django testing etc and you wanna go straight to the github actions then just have a look in the timeline and start on section four so just to kind of illustrate what it is we're trying to achieve in this tutorial so we're going to be utilizing visual studio code to develop an application eventually we're going to want to push that application over to github and now we're going to then configure or create some actions based upon an event that's happened in this case we've pushed a repository over to github or we push some code over to github so get up actions are essentially ways to kind of automate tasks um in our kind of software development life cycle here so for example we're going to create a workflow an automated kind of task which is going to automatically check the quality of our code for example that we've uploaded and also it's going to then run some tests and also run for example other applications like coverage which is going to give us some detailed information about the tests so we could go on in actual fact we're not going to do this in this tutorial but we could also write the action to then deploy the code so this is what we end up with in github after the action's taken place and completed that we've performed uh we'll see a nice little overview of all the steps that we've taken or all the steps the action has taken and then we can also then drill down and find some specific information okay so like i said you can skip ahead to different sections of this tutorial i'm just going to now take you first through creating a new github repository initializing the django directory and project and then configuring it and then pushing it over to github just go through that process using the command line i'll then go to part two where we create some simple models introduce coverage to and then we'll introduce django unit testing just a really kind of small introduction so that we can build a simple test so that we can then run it in github then we're going to move to part three and have a look at python code quality now explain this when we get to this part here but we're gonna have a look at pep8 and flake so if you're interested in learning a little bit more about that head over top part three and then like i've already said part four we're then gonna move on to github actions i'll give you a brief introduction of the structure of actions that we build and then we're going to build a set of actions so that we can test our application okay so let's get coding first of all let's go the face went there we go so that will allow us to actually do something so just to remind you again you can use the timeline if you want to skip sections i'll try and break the sections down enough so that you can just move to the next section by all means also use the code repository that's connected to this tutorial so you can easily kind of skip past different sections uh because i'm going to start from complete basics here for those who would or need this um and obviously i don't want to bore other people who know how to do this already so we're going to make a new django project so let's go and create a open a new folder here i'm just going to go to a desktop and i'm just going to type in a new project name so this is going to be called django testing this is a new folder i actually need to make the folder i guess first that makes sense django testing there we go so i'm going to create a new project folder okay so now what i need to do is create my virtual machine so i'm assuming you've got python installed on your machine um see if i can drag this up okay so this is a windows machine so i'm going to first of all um we're going to just create our virtual environment so the virtual environment bmv virtual environment i'm going to make a new folder called vamp so we'll go ahead and do that so that's just going to take a couple of seconds on yours potentially so now i can actually activate this virtual environment uh just need to navigate to this i'm using tab here instead of typing in all the commands so now i've activated i can see that it's activated here because it says the name of the folder vent and of course now i can go ahead and pip install so use the package manager pip install django would take a couple of seconds and then once that's done we need to make a new django project so now we've got access to the django admin um that's through the package that we've just installed so let's um start project and we're going to call this core and i'm going to put a space and then a dot at the end um that's important so that the core folder is provided here instead of me making a new folder called core and then the project inside of that so it's core space dot obviously it's wrapped over to the next line there we go so now i've got this folder here and i've got my settings etc inside of that and i've got the manage pi file now which i can use to create a new application so now i can just type in manage.pi and then start app and then i've got to create an app here i'm just going to call this i'm going to call this blog for now okay so now we've got a new project folder and i just need to register that because we're going to be setting up some models so let's go ahead in the core settings and just add that to the installed apps there we go okay so now we're going to connect up our github account to our package so we can start to push some data some files over to our repository that's stored on github so let's first of all start by logging in if you haven't already done so or signing up and then creating a new repository i'm going to call this um django or testing with django and then this is going to be a public repository i'm not going to add anything else here um so just testing with django create a repository and that's pretty much all we need to do here so now what we need to do is just uh connect our our project to github so that we can start uploading some files so back in our project now let's go ahead and initialize this project um so that we can use it and upload to github for example so we do that by typing git init initialize so what's happened now behind the scenes i'll just closed that is a new folder has been created in our project now you won't see that folder here so dot git folder um that's just going to store information about any changes that we made and track some of these files etc you can see that we've got these green dots now representing something to do with uh source control etc so first thing we want to do is we don't want to upload certain files to github for example we don't attract certain files um so for example the event folder here the virtual environment is a folder that we don't want to include and upload to github for example so what we can do is we can create a new file here called dot git um so this file here is going to tell git basically not to track or upload certain files and folders so what we can do is if we just head over to um if you're not familiar with this you can go over to google well actually it's just right here um head over to google type in django git ignore and then go over to the total.com page here and someone's uh created a kind of a template which you can use for your get ignore page um so let's have a look at this and what this is is a kind of a all the common files and folders that you wouldn't want to track with git so for example here we don't want to track um the event folder you can see now that automatically with visual studio code in place it's detected which files or folders won't be tracked and you can now see um it's turned to gray so the gray represents files and folders that won't be tracked that are actually inserted or defined here in this ignore file so here for example if we just move down um i think we've kind of moved past it but there's a folder here the vm folder here it is so that's an indication and indicator to not to track that folder for example so have a look at that right so now we've got that in place we can now go ahead and add our file so that we can then create our first commit so let's go ahead and do that so let's do a git commit and then we're going to just basically do our first commit uh so i'm going to call this fc for first commit so that's basically going to try to record um the current state of our application um you notice that there's a a problem because what we haven't done is uh git add so do that first and then run the commit and you can see it's find found all the files and it's kind of committed that to our i guess um our first kind of package or the base or the entry point so that we can start tracking these files so now that's all in place and what we can now do is we can define the the branch so what branch you want to use this is just going to be our kind of our main branch um our core or primary branch it might be that eventually we're working with different branches so we might want to kind of move uh data to different branches but this is going to be the main branch um so we set that up so now we need to add the remote repository where we want to kind of uh send all these files uh so let's go ahead and just copy this this is a repository we built earlier so we'll just copy this link here and we go back and we just paste that in so that's adding the kind of the origin where we want to send and maybe push or pull uh our data from and now we've got that in place we can now go and actually try this out so let's go ahead now and push this across so get push then we just need the origin where we want to push it and then we can also define we can also then define what branch in this case ours was called main so lesser tried that out now i'm already logged into github it might be that a new window appears and you'll be asked to log in and then once that's done this will take place you can see here that um that seemed to have happened okay so now we can go ahead and check the repository online so if we go back in and refresh you can now see that our project has been uploaded successfully so to quickly run you through that process again if you're not familiar so just make a change to one of your files for example and once you've made a change you'll then just need to run in this case github add and that just adds any files that you've made changes to for example you can specify what changes um you want to add to the next commit so i select dot and referring to everything and then what you need to do is you need to run a commit again so we've made changes so we'll make a new commit now so this basically means that whatever we previously saved the state as um we're now going to update it and track those new changes so we're going to call this new commit so nc and there we go so we've made it a a new commit with those new changes so now what we can do is we can then go ahead and get and then we want to push this over to the origin and then define the repository okay sorry the branch so now we've done that if we move back into uh github here and go into for example the blog and then models you can see that those are changes that we made the comment there okay so that was a brief overview of getting the new project started initializing uh your the git repository in your django project directory and then just configuring and pushing your project over to github so now we've done that now let's move ahead and we're just going to create a simple model for our application um and then i'll take you through it just an introduction with to coverage so you've got a general idea of what it is then you can go off and explore some of the other features that it provides and then i'll give you a quick introduction to django unit testing so we're going to build just a single uh test here so that we can then fire it off and start it using github actions so check out the other guides in this channel for a little bit more in depth about models etc so we are going to just build a very simple model here i'm not going to type this out so we're going to create a new model here in the blog models i'm going to call this post so we're making a blog here so we're going to create this new table essentially all this new model called post extending from models and then i'm just going to add some attributes here so title which is going to be a character field with the max length of 255 an author for example and there may be just a slug here so that we can save the kind of the url directory uh for specific posts and then we're going to create this dunder method here the string dunder method so this is a default output um for a post item that would for example appear on the admin page and then we're just going to return self.title and that's going to be the default output okay so that's a simple model so let's go ahead and now clear that oh our wrong page we'll go ahead and clear that and then we'll just run for example uh make migrations so we're just going to set up our table now oh i spell it wrong and make my equations i've done it wrong again i've got two items this time okay third time lucky there we go so we make migrations and then we're going to go ahead and migrate so that's going to apply our new migration that we've set up to the database so that's just basically going to set up the original initial django models and also this new model here that we just created so now we've got this in place we have our model so now we can potentially do or perform some testing so now head over to the test file in the blog application this would a bit this would have been automatically created for you when you created the blog application so inside of here you can see that it automatically adds a new line here django.test import test case that's essentially a wrapper around the built-in python test suite so now we have kind of access to this we can now go ahead and think about writing a test of course if you're big if you're new to test testing uh new to writing tests here in python and django um first question you might ask yourself is what do i need to test so if you're not used to or you're not familiar with testing you're not too sure what you actually need to test for example a test coverage reporting tool like the one we're going to install basically shows you how much of your code is is tested and then potentially offers suggestions on what other tests need to be created so this can be a good way of starting testing to identify what tests might be needed in your application so go ahead and install coverage so pip install coverage and then we can run coverage to make sure it's kind of uh installed properly we can just run the coverage command so pretty much every command is going to start with coverage when we're using coverage and then we can run for example version that would tell us what what version we got there we go um and then we can move on and then run some tests so we don't actually have any tests at the moment but let's just run this say coverage and then run and then we're going to need uh our manage pi and then test so the keyword here is test so you can see that it's random and no tests at all it's done that in 0.00 seconds okay so now we've done that what we can now do is potentially run report so this is all the power of coverage so let's just run the report this is going to give us a report here in the terminal so what you're looking at here is an overview of all the things that it's found within my application and then potentially where tests might need to occur or where they might be needed so for new developers maybe this isn't the most intuitive here um so what we also have is this ability to get a kind of gui interface so we can go ahead and type in coverage and html so that's going to create a new folder inside of your project um give it a couple of seconds and there it is so it's called html curve notice it goes gray straight away because in the git ignore file it's already been set up to ignore this folder so if you open up the repository for this you can see that we've got a new folder here called html cup inside of here we've got an index file so we can just open that up and there we go and you can now see in here is a little bit of a more intuitive report and you can see we've got the blog admin for example uh what we've got here we've got this new app here called blog we've got uh models here and notice that we're missing one test so it suggests that we're missing one test and i can click on this link and that that drills down then into that page and identifies where potentially a test is required now notice that for example here it's gone into the event folder and has provided me loads of information about the packages inside of the virtual environment folder so there's always going to be a case where you want to kind of exclude folders and files so we can also do that with coverage so what we need to do is just type in coverage run and then the double dash submit equals and then the folder name in this case vent so we're going to run our tests utilizing this so after this obviously we're going to need manage pi and then test so that's going to run the tests and so this time when we kind of run our coverage again html that's going to regenerate uh the reports and then we can go back into our our index again and this time you can see that it's excluded all the virtual environment folders okay so now we've got that in place let's go ahead and just build a simple test so back into our let's just uh remove all this for now so let's go back into our blog and we're going to go into our tests so we've imported the test case and that's going to provide us access to the python test framework so that we can run some tests so what we need to do here is to build some tests so we start off with a class and we're going to call this model testing for example so i need to bring in test case so i have access to all the tools i'm going to need to test and now what i can now do is set up some functions so the first function that you might want to set up is would be called setup okay so we're going to take in self so if you're not familiar with self so the self parameter is basically a reference to the current instance uh this current instance of the class and it's basically used to access variables that belong to the class so it allows us to kind of access um other variables or allow us have access to other variables in this class so his self okay so now we're going to set up an instance of our database so what's happening here in our tests is that we want to test the database now we've obviously got the production database or the main database of our application when we run some tests we don't want to we're not going to initially utilize that database we're going to set up a separate testing database so that we can then run some tests so what we need to do is actually we need to build that database so we're going to need to bring that database in so from dot models we're going to import that so it was called post so bring in that model so that we can replicate it in a new database now we want to set up so what we're going to do here is just create some new data for our database so we're going to say self dot and then block and that's that's a variable that we can then utilize to access that data in another function and now we're going to take the post table now we need to use the default manager so which is objects so that's the default model manager objects and then we're going to use the keyword create and that's going to allow us to create some new data in our database so what we're going to need here is we're going to need a name because that's the first attribute or field in our model if i remember so we're going to need a title author and slug and these all character fields and a slug so let's just go back to our tests so name and that's going to equal just uh let's just call this django and then we also had author space author equals and that's just going to be django again and we're not going to put anything inside of the slug oh no let's do it let's do it slug equals and then we're just going to say again django okay right so we've got a name an author and a slug so that's what's going to be created we're going to create a new instance within our database and then we're going to make that available through this variable here so now we've got this set up this data set up so what's going to happen here is that when the tests are run this is going to automatically run first and it's going to basically prepare this inside of this variable here blog so what we now need to do so let's go ahead and now build a test or something to test again so uh let's go self and then we're going to use assert true so you can see there's a number of different assets here and essentially what we're building here is the logic uh almost i like to think of these at least begin with uh or describe them as kind of um functions um that perform an action so if you think about here what we're doing is we're running a kind of a simple if statement say um that's one way to think of it so we're saying here um in this case if our data does go into the database then what is returned is true so therefore we're going to run an assert route to check to see if we return true based upon that function and if it is true it means that our test is successful and our data meets the requirements or matches the data type in this case for our table so we're expecting character fields in the slug field so here we're essentially just checking to make sure that our data is modeled correctly to our model okay so asset true so now what we need to do is actually set up the test so for example is instance so we're running an instance here so we're going to put an instance inside of our database so and the data is d and then the data base is going to be post so we're going to take this instance here and we're going to try and put it into our post table right and if it is true if it does work it's going to return true therefore the test will pass so let's just give this a go to see if this works so we're just going to run in the terminal of course uh py manage pi and then just the word test so we return okay and there we go we ran one test so how it's running one test is because if we go back here django's going to pick up any files that begin with the word test um or name test so tess so you can see that django automatically finds this file and then runs those tests so back to our coverage report previously we looked at the um where is it the models and there was one test that needed to be completed and that was to test to make sure that a post returns and by default the title so that's kind of a string return if we were to if we were to collect one of these items in this table what would get returned is a reference and that would be that the title of that instance that is returned from the database so let's go ahead now see if we can build a test around um ensuring that that is complete so we'll do it uh just below here so let's go ahead and do self now we're going to use one of these other tools so this time we're going to use assert equal so we're going to check to see if something's equal so as whereas before we check to see if an outcome was true now we can do assert false as well for example so here we've got a cert equal so we're going to check to see if two things are equal so if one equals one then assert true is going to be true so a certain equal is going to be true therefore the test will pass so this time we just need to define the two things we want to compare in this case so the uh string from the instance so that's the string return from the instance um so remember what gets returned by default is um the word django from the instance so d and then what we need to do is define the actual thing to compare it again so what should get returned from this instance is the title that's the uh string return here self title so we know the title is called django so we can then compare it against the word django and then we're just going to run that off so let's just do another test and now you can see we're just running one test again so this is one suite of tests here um of course we could break this up into two tests if you wanted to but this is just one suite of tests that's why it says run one test um right so what we can do now is just mix this up a little bit so let's just uh make it a fail for example there we go so now it's failed and we get this failed message here and it gives us a general idea of what potentially is the problem um so not there just here uh so here for example it says it's not equal so it's returned django but it's not equal to what we're expecting or what we've written django with an s so therefore should we make some changes so it's kind of clear what it is that needs to be changed so now we've run this test or we built this test let's go ahead now and uh just update and see if we can now change what has been returned here in coverage to see if we can get this to go to 100 so let's go ahead and go back into the let's go back into the command prompt now just save a little bit of time i'm just going to type that in so we're just going to use coverage now um admit the event folder so we just run that again and then we can then run the the coverage html again so that's just going to recreate the page here so we can just refresh let's just go back here so refresh and you can now see the models are 100 completed and there isn't any missing because we've just built this test here for that okay so that was some really simple unit testing there with django introducing this idea of coverage um again there'd be some other tutorials on this channel which you could then follow and go in a little bit more detail i just wanted to get that up and running for those who haven't used testing before so now i want to introduce something i've not done before on this channel uh talking a little bit about code quality i want to introduce you to pep 8 and also installing flake and having a look at how flake can uh create better code or improve the quality of our code so code quality generally refers to a number of different things but generally good code quality is considered to be well tested it follows maybe consistent styling so this is why i'm introducing for example pep8 in this case it needs to be understandable you know we need to make sure that um it's well documented uh in certain places potentially it's easy to maintain by following essential kind of coding guidance and methodologies for example and of course we want to avoid any security vulnerabilities so when we think of code quality we can compare our code to those type of qualities so without going into some major detail here uh basically pep 8 if you just type it into google it's easily readable here basically this is some guidelines some official guidelines that provide us some best practices on how to write python code you can see here from reading this that pep 8 is suggested to improve or focus on improving the readability and consistency of the python code so there's quite a lot to this in actual fact if you go over to the python.org and have a look at the pep 8 there the style guide you can see that the contents is quite long so it would take a fairly long time to cover all these aspects here but let's just go through some of the basic things here or indeed we might not need to read this at all because this is why we're going to install a program called flake so let's just follow the the path here so i mentioned pep 8 it's a style guide for python code so have a look through that then what we're going to do here to kind of enforce that styling guide is we're going to install flake 8 now flake 8 this project here basically like it says is a wrapper around these tools so when we install flake 8 it's also going to install this pie flakes and the pie code style and also the the ned mccabe script so these rings are going to be installed so pie flakes essentially this is a project a simple program basically which will check python source files for errors so it's going to kind of analyze the program in text various errors that might be in our program so next up here we've got the pi code style so this is going to perform similar actions again it's going to have tools inside this package which is going to check our code against kind of some of the conventions that have been described in the pep8 so let's just go ahead and get this installed so i'm going to copy this across and i'm going to install so pip install flake eight so now that's available i can now run flake eight and then what's going to happen now is going to scan through all my python files and it's going to then produce a little report potential of some of the errors and changes that are going to need to be made in order to kind of meet some of these style conventions so that's going to take an incredibly long time to probably work and you can see that it's trying to access all the event folders so clearly we don't want to check the styling of any of the code in the event folder so we're going to need to find a way of kind of excluding files similar to kind of like the git ignore here we're going to need to find a way to kind of ignore some of these files and folders so what we can do is we can create a new file here this is going to be a setup dot config and then in here we can define some parameters uh for flake eight so in here we can for example exclude uh and then we just define what we want to exclude so dot git for example um maybe any migrations for example and then of course we also want the event folder something like that okay so another stylistic convention is that typically uh fl pep 8 is going to define um a maximum line 9 line length sorry of 79 characters now if we don't want to enforce that we can head over to the django admin sorry and then if we look down at the pep8 convention and have a look at the style convention used for django it looks like they're using or allowing up to 119 characters so what we can do is we can also change our parameters in the setup here and we can for example set the max line length and that's gonna equal one one nine okay okay so that would then be some overrides or some additional configurations for flake eight so let's go ahead now and just type in flake 8 again shouldn't take as long as last time because we're not going to scan the event folder for example and you can see here we've got some very clear instructions on what needs to be changed in order to meet some of these specifications so what's also important here is that we can see that these flags have been created all these error numbers have been designated to particular types of errors and this can be really important once we start setting up our github actions because we can perform certain actions if we do find certain errors now it might be that we have certain specifications within our software development which means that oh we want to actually overlook this for example now the problem is here if we run this in github actions there might be it might cause an error so we can kind of override based upon or dismiss certain errors or for example in github actions we can set it up so for example we can capture certain areas that we want to capture and if there is that particular error it means that we don't want to then go ahead and deploy that piece of software so it's a natural error that we can pick up for example so these error codes are really kind of useful for that as well so you can see here we've got admin pi one one um imported but unused so in our admin file here the fact just is identified the fact that we've imported this in this is obviously automatically created um by django but we're not actually using it so the code shouldn't be there necessarily so that's kind of a good code and practice right so let's just uh do that one and you can see that when i run it now it's disappeared so models again two blank lines found one so one of the stylistic conventions if we go into the models here is we must have two lines um between our classes for example here so if we move and make a new line there and go to play eight you can see that one has now disappeared um so there's a general stylistic convention that there should be a new line at the end of the file so in our models we just need to make sure that there is a new line and get rid of the white space and then we can run it again and now we're going to run in the tests so four one so tess online one so we're just expecting a line breaker two there and then in the uh django shortcuts import and use okay so let's just do that one and in the views just get rid of that let's just start by default because we've created a new project and there we go so essentially what we've done now is that we can say that our code quality potentially has been enhanced through utilizing and following certain standards so our code is now fully tested and also we've implemented some code quality steps uh using pep 8 type of parameters and obviously the flake wrap around more other applications that perform code quality checks so now we can move on to github actions so welcome to github actions so let's have a look at the github action tab so you can see this is going to be in your repository by default so github actions allows us to automate tasks so this is a great part of our software development lifecycle so when we start thinking about devops ci cd and so on here we're going to perform some actions on our code so what we can do essentially is what i've kind of spout out before is that we might want to push some code over to our repository and then an action takes place so obviously what we're going to do is we're going to set up some testing actions on our django code but of course we might go ahead and also deploy once we've tested that's something else that we could possibly do here so what we can do to start off with if you're new to this if you look further down here there's some kind of templates we can utilize or at least start off with and what you'll find is if we select for example a basic python package set up this workflow what happens is that in our repository you can see there's a dot github folder workflows and inside of this is a yaml file here which we're going to utilize to define our actions course you could build this manually in visual studio code so i'm just going to get rid of this i'm just going to commit this page i'm going to rename this testing for example and then i'm just going to commit this so obviously now we're in a situation where if i go back to my book go back to the repository there's a new folder and that's much more up-to-date than what is currently here in my terminal so what i need to do is i just need to kind of pull that down and update my repository here so let's go ahead and run the get pool and then of course i want to call the origin and we can say the repository main there we go so you can now see that i pulled that down and we have a new folder here that's what's just that's what's just been created on github and you can see we've got the testing and there's nothing inside of it so now we're going to build up this actions uh this action so that we can do some testing on our application automatically so the anatomy of a github action is fairly simple process so first thing that we can do is we can just define a name i think this is a an optional thing but we can give this a name so once we've decided on name the first section really is the event section so this is basically defining a specific activity that's going to trigger the workflow that we're going to develop here in this activity so kind of some basic triggers that we can think about initially is for example if we run a push to our repository we might want to run this action that's what we're going to do in this tutorial but alternatively we could also set it up to when someone pulls the repository or potentially we could also set up a a job a cron job which will run at a certain time and these these actions that we perform here or define here will run at that time so let's go ahead and use the keyword on and then we just basically need to define now so in this case it's going to be push so we're going to define the fact that when this repository is pushed when there's uh new files being pushed this repository um something's going to happen now we can also drill down a little bit further into branches so if you've got multiple branches in your in your repository we can also have a look at those individually and then we can define them what branch we want to run this on one or multiple okay so the syntax might alternatively you might see in the syntax using uh the brackets here so we could also run it like this for example okay so now we've defined that alternatively we could also run this on pull so we could also just now just say pull request so we can define it on this too and then again we can go ahead and just identify the branches we want to work on and in this case we've only got one branch called main space that okay so just to give you a little brief overview um if you were going to set up a schedule so here's a schedule this is obviously been commented out um we can set up a crown here for the different time so you've got minute hour day month and day of the week so we can set up a chrome activity here to run at a certain time okay so now we've set out the event defined uh when these actions are going to take place that we're going to or steps that we're going to perform now we're going to build what is a job or refer to a job so a job is basically a set of steps that we're going to execute and you'll probably hear this word runner which i'll explain shortly it's going to be executed on the same runner here so let's go ahead and now set up our job so we're going to find some parameters defines how the job or the environment of the job and then we're going to define the individual steps here so let's go ahead and what we're going to need to do is run a job and then we're going to run a build okay so what we're going to need to do here with this build essentially what we're saying is that in order for us to actually run this code and run these tests that we want to run we're going to need some sort of operating system to do that on we're going to need some sort environment so in the back end what's going to happen is we can define a the working environment we want to run these tests on so there's a few different options here but we're just going to say runs on and then ubuntu and the latest version of ubuntu so this is obviously avoiding the many different uh options here but basically what's going to happen here is that github is going to spin up a virtual environment with ubuntu the latest version of ubuntu is then going to run our commands that we set in our program inside of that environment i guess that's how we can think of it at this point okay so we've got runs on so we've defined that have a look at the manual for all the different other different steps if you want to then move a little bit further but now we're going to define some steps so what we're going to need to do is to actually get our code in to that environment so what we're going to need to do is to run these pre-defined kind of actions that have been created um so action and then we're going to need a check out um i will use version two so like i said this is basically going to take our code kind of connect everything up so it puts our code into that virtual environment and sets things up so that's a nutshell what's happening there and now we can do is set out a name so what we can now do in each step of our process we can define names and that's basically defining different sections of our tests that we want to run and that would then also then be depicted on the outcome of of our action so we have a nice little list so for every name there will be a list item within that list of events that have occurred in these actions here so we match that up at the end so let's just give that a name um so we're going to start off by we're going to set up python um and we're going to be running 3.7 and imagine at this point um so we're then going to define users so again we're going to use some other actions um that's going to set up uh that's going to set up python on this environment so we're going to use the setup python and that's going to be version two as well okay so that's essentially i'm just uh generalizing here but essentially what's happening now is we've got this operating system we're now going to set up python for this environment and now we've done that um we can now kind of define um what version so with and this is going to be python version so we can define what part conversion we want 3.7 there we go and there we go so now we've kind of set up our environment ready for us to now go further and start bringing in our code and running our code etc so let's first of all we're going to create a new section so we're going to have a name and now what we want to do is we want to kind of install or the dependencies right so we're going to now install all the dependencies uh so we're now going to run the new command run so we can now actually run command so imagine now we've we spun up a new virtual machine we've now set up python automatically now we're in the console so we're now running commands here as if we are in in that console so we're going to run some commands so python has been installed etc and it's available so we're going to run python minus m and then as we do to kind of start off with generally we're just going to up upgrade pip for example so get pip upgraded that's the package manager and then what we can then do is install all the dependencies for our project now which is normally in the requirements dot txt file we need to build that in a second and there we go so that's kind of the first step that's going to happen so these two commands are going to be run on the terminal and now we can then go on to the next stage so everything is ready for us now to start doing our testing so we have the name and we're now going to kind of lint uh with flake flake eight now for those who are not familiar with that kind of coding terminology there linting or lint uh linton like says here's an automatic automated checking of the source code so that includes stylistic errors so notice and remember we're going to set up pep 8 and that essentially is part of his linton process it's going to check the stylistic for stylistic errors for example so this is why i've called it um lint with flake eight so let's just go back uh limb with flake eight uh now we want to run some commands so run so observe all the tabbing and um spaces uh so run and now we want to first of all pip install flake 8 now we won't need to do this because it's probably already installed in the requirements text here but i'm just showing you a general case so let's uh first of all install it and now of course we can just go ahead and run it so just a flake eight so at this point you probably see where this is going so we've installed and we've uh run that so now we can then go ahead and go to name and now we want to do the coverage a report so let's go ahead and do that in our case uh so um now we need to of course uh run some commands again so we're gonna pip install uh coverage and then obviously we can then run coverage so it's going to be coverage and then run manage dot pi and then we want the keyword test okay so that's going to run the tests [Music] and then next up we want to then of course just run the report so we can do a coverage and then report remember there was two reports that we can build we can obviously build a html page or we can just use the terminal of course at this point we don't want to start building a html page etc so let's just go with the terminal so we're going to need coverage and then report okay so that's coverage so at this point of course you kind of start to see the uh the style or the convention here so let's just create a new name let's just call this django testing of course we don't need to do this this is just uh just to add something here and familiarize ourselves with this so what we can do here is we can run a command so let's just run for example python 3 manage dot pi and then test obviously that's just going to start the tests again which is already done we know um but there we go so there we have our script now in place i'm just going to save that so let's go ahead now and get add let's just do everything again and then we're going to git commit it's going to be a new commit and you can see there's going to be a few changes here and then we just need to push it on so let's uh push it over to the origin and we're going to use main so hopefully what will happen now is that if we go back into our repository here and go to actions you can see here 15 seconds ago it tried to actually run the workflow so you can see that there's an error which is good so it says no steps defined in steps for the following jobs build so just looking back into the code you can see that i've typed in step instead of steps so while we're here i might just check the rest of the code and so we've got user name username okay so it was just the the s i think we had a problem with that so let's just go through the same process again and just get that migrated so hopefully you've become a little bit more familiar with those commands of course in practice you wouldn't probably do that you potentially use the extension here or github desktop at least to begin with so let's go back into our repository and then go to actions again so this time it looks like something's happening it's gone yellow so we can follow and track our build as it progresses through the stages if i just click you can see here we've successfully got through to the installing dependencies and this is where it's going to fail obviously because we've forgotten to add our our file here so what we're going to need to do here is create a file called requirements.txt to now pip freeze which is going to define all the dependencies that are needed to run um to run this application and testing so it calls out our requirements dot text that's what we've defined also in our setup so we're going to install the requirements.txt okay so inside of our requirements.txt then is all of our applications that we installed so you can see it's got flake etc here now obviously this is already going to also be installed again remember here we're just asking it to be installed again here because potentially if this was a production environment you potentially wouldn't include that in your requirements um there'd be no need for you to um include that as part of a deployment onto a server for example the uh the coverage or the flake for example so let's now go back and um go through the laborist activity of committing and then it back so now we've updated this again so let's go back into our actions so we've run a new job again so we can remove these and we can delete these workflows here if you want to so we start again having a look at the build so this time you can see it's actually installing all these dependencies and we've got to the installing dependency so you can actually see all the commands as they go along so you can see that the uh with ram one test looks like it's okay um that's very quick um you can see that we've got the output here of coverage if we wanted to see that and obviously we can use the what i described earlier in the coverage section um the different commands to do different things here output different things here uh we've got some the general general django testing we did which is obviously similar to the coverage that we performed that was just for the case of doing that and there we go so we have some kind of actions to do some post activities to tidy up some things and then the job's complete so we have a clear overview of exactly the workflow that we've just done we've got the build it looks like it's working okay and there we go so there we have a very simple workflow of creating a new django project setting up some tests uh thinking about code quality and then creating a github actions so that we when we push to our github repository we can run some tests automatically now obviously in hindsight or in reality you probably want to do those tests before you push your code across but obviously it's good to have these type of safeguards in place of course and for many different other reasons and potentially just setting up so when you push to the repository it gets checked okay so i do hope that's kind of wet the appetite for more github actions with django obviously this is just a simple introduction to github actions and django and setting out some important aspects like testing and code quality thank you very much for listening and i hope to see you in the next tutorial

Channel: Very Academy

Views: 4,882

Keywords: Django, github, django github, github actions, django testing, django unit test, django and testing, test in django, django tut, django tutorial, django 3, django examples, learn django, django beginners, beginners django, django framework, django example, django testing models, django model testing, django, django 2021

Id: qJPLFDtEi1I

Length: 60min 14sec (3614 seconds)

Published: Tue Jan 26 2021