Python Tutorial: Unit Testing Your Code with the unittest Module

hey there how's it going everybody in this video we're going to learn about unit testing in Python so we'll go over how to write tests how to setup and teardown your test and also some best practices so if you're not currently testing your code then it's definitely something that you're going to want to learn and start adding to your projects so a lot of you have probably heard of testing but you might not know exactly what it is testing your code is the most exciting thing to do but there's a reason that most companies and teams require their code to be thoroughly tested and if you're going to get a job working on any large projects then you're going to need to know how to properly write tests and the reason for that is that it's going to save you a lot of time and headache down the road so when you write good tests for your code it gives you more confidence that your updates and refactoring don't have any unintended consequences or break your code in any way so for example if you update a function in your project those changes may have actually broken several sections of your code even if that function itself is still working and good unit tests will make sure that everything is still working as it should and if it's not then it will show you exactly what's broken so in this video we're going to be going over everything that you need to know to get started with the built-in unit testing module so with that said let's go ahead and get started so right now I have a basic script pulled up here that has some simple functions and I want to start off using these really simple functions so that we can just focus on what the tests look like now what a lot of us start doing to test our code is just put in print statements and occasionally run the code so for example down here at the bottom if I wanted to test that my add function was working I could just say print add and add together ten and five and if I run that then we can see that the output that we got looks right but testing your code this way isn't easy to automate and it's also hard to maintain so also if we're testing a lot of different functions then there's no way for us to see at a glance what failed and what succeeded so that's where unit testing comes in so we're going to go ahead and just move remove this print statement and actually start adding some unit tests so to do this first we need to create a test module so I'm going to create a new file here in this current directory and I'm going to call this test underscore calc dot py now that's the naming convention when writing tests is to start with tests underscore and then what you're testing so in this case it was test underscore calc and that's actually going to be required within our test so now we have this test underscore calc module pulled up and we're currently working with an MP file

so first let's import the unit test module now this module is in the standard library so there's no need to install anything you can just say import unit test and now we're also going to want to import the module that we want to test so I'm going to import that calc module and we can import calc from here since it's in the same directory now if you're testing code from a different directory and can't get your imports to work then you can watch my video on importing modules and it should help you figure out how to properly get that set up so now we need to create some test

cases for the functions that we want to test and in order to create those test cases we first need to create a test class that inherits from unit test dot test case so to do this we're first going to create a class and we will call this test calc now you can call that class whatever you like but try to keep it descriptive as to what you're testing and we're going to want to inherit from unit test dot test case so inheriting from unit test case is going to give us access to a lot of different testing capabilities within that class so let's write our first test so to do this we'll write a method and the method needs to start with test underscore now that naming convention is actually required so that when we run this it actually knows which methods represent tests so if the method doesn't start with the word test then they won't be run and we'll see what that looks like in just a minute so ours will be test underscore and then what we're testing so first we'll just test the add function of our calcul so we'll call this test underscore add and just like any method in a class this takes self as the first argument and now within our method we can write our test so since we inherited from unit test case we have access to all these assert methods and I have them all pulled up in the documentation here over in Chrome so we can see that we can assert whether two values are equal with assert equals not equal with assert not equal true assert false and the documentation shows you exactly what all of these check for so for example assert is not none checks whether a variable is not none so the documentation has a good overview of all these asserts and then over here what it actually checks for and I'll also leave a link to this in the description section below so now let's switch back to writing our test so we're going to use assert equals to test our add function so I can run our add function from here by saying something like result is equal to calc add and we'll just add those same values 10 and 5 and we would expect this to equal 15 so to test this we can say self dot assert equals and now we want to assert that result is equal to 15 okay so now how do we run this test so we could do it from the command line so I have my command line here pulled up and I am navigated to the directory where our module is currently located now you might think that we could just run the test by saying you know Python test underscore Cal PI but if I run that you can see it doesn't actually return anything so instead we need to run unit tests as our main module and pass in test underscore calc and we can do that by saying Python - m and then unit test and now the test underscore calc I module and we can see that when we run that it puts a dot here and it says one ran one test and at the bottom it says ok so that means that everything passed now it would be nice if we could just run our tests using this first method here by saying Python test underscore calc and just running the module instead of using this longer command here and setting it up to run that way but also allow us to run our test from directly within our editor so to do this we can just come down here to the bottom and we can say if name double underscore name is equal to in quotes here double underscore main and then within this conditional we can just say unit test dot main and run that now if you don't know what this double underscore name equals double underscore main is doing this actually isn't related to unit testing at all I do have a separate video specifically what that is about but basically it's just saying that if we run this module directly then run the code within the conditional and that code within our conditional is this unit test dot main and that unit test dot main will run all of our tests so now if we go back here this is now saved to our terminal and I will clear this out so now let's rerun that using that first method of just Python and our test module and if we run that you can see that now we can run it directly and it runs our unit test and says that it passed and since we can run it this way within the terminal that should mean that it can also run within our editor so if I run this then you can see that within our editor we can now run these tests also okay so that's good so we're running our first test so it's saying that we're only running one test now do you remember earlier when I said that your tests have to start with the word test well let me show you what it does if it doesn't so instead of test underscore add here as our test let's call this add underscore test and save this and run it so when we run this it might not be obvious right off the bat that anything is wrong because we didn't get any errors or any warnings but if we look at how many tests ran it says zero so this test would just skipped so you have to be careful that all of your tests are named properly and start with the word test so let's go ahead and change that back and rerun it okay so now what happens if our test fails so let's change this value here with the assert equals the result is equal to 15 let's change this to a 14 so that our test of adding 10 and 5 fails so let's save that and run it so now if I pull this up a little bit here to where we can see that in stead of a dot an F for fail and it also shows us that the test failed with an assertion err that 15 is not equal to 14 okay so now let me pull this down just a little further here and now let's change this test back and also add in a few more tests so first of all instead of setting this result variable and testing that I'm just going to instead drop our function directly into the assert statement so I'm going to copy this and replace that result variable actually with our add function and then I can just get rid of that result variable there so you usually want to also check some edge cases so let's copy and paste this line here a couple of times and

test a couple of edge cases so one edge case might be one negative number and one positive number so let's make sure that negative one plus one is equal to zero and two negative numbers would also be another edge case so let's make sure that negative one plus negative one is equal to negative two so now if we save this and run it then it's saying that it passed but it also says that it ran one test now you may have been expecting this to say that it ran three tests but really these three assert methods here are just within this single test called test underscore add but even though it still says that there's only one test we still made this test better by adding in these additional checks so it's not our goal to write as many tests as possible but just make sure that we write good tests so that's something that a lot of people get tripped up one they just shoot for you know full coverage without making sure their tests are actually good enough to catch mistakes so try to be mindful of that when writing tests and in order to add more tests we just

add in more test methods so let's test the rest of our calc functions so I will just copy and paste this test add function here three more times and I'm going to get rid of our output here so we can see a little bit better and now I'll change these to test all of our calc functions so I'll test our subtraction function by changing all of these ones here too correct and now let's change our assert equals so 10 minus 5 will be 5 negative 1 minus 1 will be negative 2 and negative 1 minus negative 1 should be 0 and now moving down the line here let's change this next test to be multiplied so now for our assert equals we want to test that 10 multiplied by 5 is 50 negative 1 multiplied by 1 is negative 1 is 1 and then let's change this last method here to test our divided function so we want to test divide so now in our certain statements here we want to make sure that 10 divided by 5 is equal to 2 negative 1 divided by 1 is negative 1 and negative 1 will just be 1 so now if I run this code with all 4 of these tests then you can see that we got 4 dots and it says that we ran 4 tests and all of those tests pass with all of those assert equal statements so you can imagine how useful this is so if you have a module with some complicated functions then once you put in the work to write good tests like this then you can just come back and rerun these tests to make sure that everything still works so if you change something in your program that you think will work but it actually broke some stuff then your test should catch that so for example let's say that I came in here to our calc function and we just made a typo in this multiply function and instead of 1 asterisk there we put 2 now this is actually going to return X to the power of Y so if we come back here to our tests and rerun this then we can see that if we look here at our output that we have 2 dots and then an F and then a dot so that means that 3 of our tests pass and 1 test failed and the one that failed it says that we have an assertion error that the 10 times 5 should actually be equal to 50 and it's not instead we got this value here so that gives us an idea of exactly where the problem is and where we can make that change to get these tests to pass again so let's go ahead and go back here and change this back now sometimes you might make a change that doesn't actually break your test but well actually unexpectedly break your code so for example let's say that we came in here and changed our divide function to be for division instead of regular division and we can do this by changing this to two division signs now if you don't know what floor division is basically it just doesn't give you the remainder now our current test won't catch this because right now all of our and let me save this here so right now all of our divisions currently come out two whole numbers anyway so it doesn't matter for using for division or regular division so if we run our tests and we can see that currently all of these tests are passing so let's say that at some point that for division broke our program and after some debugging we traced it back to that and found the problem now in that case it's always a good practice to go update your tests with a test that would have caught the problem that you just found that way we can know that we don't revisit the same bugs over and over so for example a test that would have caught this I'm going to copy in a sequel statement here now a test that would have caught this is if we would say you know 5 divided by 2 we want that to actually equal 2. 5 but with floor division that's actually just going to equal 2 so now if we run this then we can see that we got our error because we're using that floor division and we can see that it is an assertion error that 2 is not equal to 2. 5 so that should point us in the right direction and then we can go and see why that would be the case and then we can find out that we're using floor division there instead of regular division and fix that go back to our test and run it and now they're all passing ok so now there's one more thing within our calc file here that we can see here that we are checking if the number that we're dividing by is zero and if so then we're raising a value error with the message that we can't divide by zero so we'll likely want to test that our expectations are working on that as well so but this is done a little differently than the other assertion so let's go back to our test and show how we can test that dividing by zero raises this correct error so there's actually two ways that we can do this so first we could say self dot assert raises and within assert raises first we want to pass in the exception that we expect and that is a value error and now the function that we want to test and that is calc divide now we're not putting parentheses or any arguments there we're putting the arguments as arguments to this assert raises method so let's look at this one more time so our first argument is the exception that we expect the second argument is the function that we want to run but we aren't passing arguments to the function so leave off the parentheses and then we pass in each argument that we want to pass into the divide function separately so now the reason that we have to do it this way instead of just running the function normally is because our function would actually throw that value error and our test will think that something failed but we'll look at a way that we can do this right after this test so right now if we run this then we can see that this is currently passing and that's because the 10/0 did throw this value error so if I was to change this zero to a two then it's not going to throw that value error so if I run that then it failed and we can see that the assertion error is that value error not raised by divide so which makes sense if we divided by two so if we divide by zero that test passes now I've never preferred this method of testing exceptions because I just like to call the function that I want to test normally instead of passing in all of the arguments separately like we're doing here and we can do this if we test

the exceptions using a context manager now that will allow us to handle and check the exception properly and also call our function normally so to do this I'm actually going to get rid of everything here and to do this we say with self dot assert raises value err and that's using the context manager and within this context manager we can just call our function normally like we normally would so calc divided and we'll divide 10 by zero and save that and run it then you can see that by using this context manager that all of those tests still pass so you can choose either method that you prefer but I've always preferred to use the context manager when testing exceptions okay so now let's look at writing slightly more difficult tests so I have a simple employee class here and this is the employee class from the object learning series and if you don't know exactly what this class is doing then it's not really important we're just going to see how this affects some testing strategies so basically what this code is doing is that allows us to create employee instances where it will set the employees first-name and lastname and pay and then we have some methods that return the employees email address which is their first name and last name at email com then we have a method that returns the employees full name which is just their first name and last name combined and we also have a regular method here where we can apply arrays and it will set their pay to the current pay times the Rays amount which by default is 5% up here now the way that this code is set up if an employee's first name or last name changes then that should automatically be reflected in the email and first name okay so let's say that we wanted to write some tests for this so first what we would do is we would create a new file and I'm going to call this test underscore employee dot PI and to save time from you watching the type all of these tests I'm instead going to grab them out of my snippets file here and we'll explain exactly what we're testing so I'm going to copy all of these down to this point and paste these in here okay so if we scroll up to the top here then first we're importing unit tests and also importing our employee class from the employee module and then we're creating our test case that inherits from unit test case and then we have three different tests here so our first test is called test underscore email and this creates two employees here and when these employees are created we should immediately be able to access the email property so we test both of their emails to check if we're getting the expected values and then we are changing their first names and then checking the emails again here because their email should change with when their name changes so this test email is just testing to make sure that all that functionality is working properly and then when we test the full name it's basically the same thing we're creating two employees and then we're checking their full names to make sure they were created correctly then we're changing their first names and then we are rechecking to make sure that the full names were changed as well and lastly we have a test for testing the apply raise function here and again we are creating two employees and then we are applying a raise and by default that's 5% so we just test to make sure that the pay was raised by 5% so this is basically just a slightly more complicated test than our simple calculator test but there isn't anything here that we haven't seen yet so we just have three different tests and have some assert equals in here to make sure that things have the values that we expect so if we run this and we can see that all of those tests pass now one thing that you might notice is that at the beginning of every one of these tests we are creating two employees now anytime you see the same code over and over that should be something that pops out to you that there might be a better way of doing this because usually programmers try to make their code dry which stands for don't repeat yourself now the reason for that is because if anything ever changes with these to setup employees here then we'll need to make changes to every single test where we created at these employees now this might not be a big deal when we just have three tests like this but if you have hundreds then it could be a pain to maintain so it would be nice if we could create these from scratch in one place and we you them for every test and there is a way to do that so that's what the setup and teardown methods are for so at the top of our test class here let's create two new methods and one of these is going to be called a setup and then self as the first argument and for now we'll just put in a pass statement there and the second method here will be tear down with self as the first argument and another pass statement now these are camel cased with the upper case U and the upper case D so be sure that you type those correctly Python usually doesn't do that but I think this is carried over from some older code so the set up method will run its code before every single test and the teardown method will run its code after every single test so for example we wanted to create these two employees before every single test so we can come down here and grab what we're creating these employees and I'm just going to copy that and paste it here within the setup now in order to access these from within our other tests we're actually going to have to set these as instance attributes by putting self dot employee 1 and self dot employee two now if you don't understand how these instance attributes work then I do have a video in my object-oriented series where I go over exactly how those work but now that we have these within our setup method now we can delete the creation of these employees from the beginning of every test so I'm going to go down and remove these from the beginning of all three of these tests and now since those are instance attributes everywhere that we reference employee 1 and employee 2 we need to add self to the beginning so I'm going to do this with the multi cursor functionality here within sublime text but in your IDE or editor you could just use a simple find and replace so I'm going to grab all of these employee ones here and just add a self dot before that and then I'll grab these employee twos here and had a self dot before that so now one more time let's go ahead and just look at this one more time here so within our setup we're creating these two employees and it's going to create these before every single test so now here within our test we're saying okay self dot assert equals and make sure that this employee that we created up here in the set up is equal to this email and this employee to Z mail we can reuse those same employees for every single one of these tests and they get created anew so let's go ahead and rerun this and make sure that this is still working and it does look like all three of these tests are still passing now we're currently not using our teardown method for anything but I still wanted to show you that it exists just in case you have a use case for it so let's say for example that you had some functions that you wanted to test that added files to a directory or to a database then in your setup method you could create the test

directory or the test database to hold those files and in the teardown method you could delete all of those so that you have a clean slate for the next test now just to be more clear where all of this code is being run let me grab some code here from my snippets that has print statements included throughout all of our tests so I'm going to grab from here down and replace this employee test here now this code is exactly what we just had but now we have print statements throughout our code so we have a print statement in the setup and in the teardown and also within every single test case so now if I go ahead and run this and scroll up here to the top then we can see that we have the setup and then the tests and then the teardown and it does this for every single test set up the test and teardown set up test teardown now another thing to notice here is that the tests don't necessarily run in order so you should never assume that the tests run straight down through the script now that's why we need to keep all of our tests isolated from one another now sometimes it's also useful to have some code run at the beginning of the test file and then have some cleanup code that runs after all the tests have been run so unlike the setup and teardown that runs before and after every single test it would be nice if we had something that ran once before anything and then once after everything now we can do this with two class methods called setup class and teardown class now I have these in my snippets also so let me grab these so we can see what these look like and I'll paste these here at the top of our test and let me fix the indentation there okay so we can see that these are class methods and if you don't know what that means basically it means that we're working with the class rather than the instance of the class like we were with self now I have an object or a video on this as well where I go into this concept more in-depth and I'll leave a link to that in the description section below but once we have these class methods in place with these naming conventions of setup class and teardown class with that camelcase if we run this code and if we scroll up here to the top then we can see that it runs setup class first and then the setups test and tear downs for each test and then at the very end here it runs that teardown class now the print buffering is a little strange with that so it ran after this line here but it ran teardown class at the end of all those tests now this setup class and teardown class can be useful if you just want to do something once and it's too costly to do before each test so for example maybe you want to populate a database to run tests against now as long as you're just reading from the database then it might be appropriate to just set this up once in the setup class method and then you can tear it down in the teardown class method okay now I know that this video is getting a bit long but there's one more thing that I wanted to show you about unit testing that I think is important for most people to know so sometimes our code relies on certain things that we have no control over so for example let's say that you have a function that goes to a website and pulls down some information now if that web site is down then your function is going to fail which will also make your test fail but this isn't what we want because we only want our test to fail if something is wrong with our code so if a website is down then there's nothing that we can actually do about that so we're going to get around this with something called mocking now there's a lot that we could look at in terms of mocking and it could probably be a video all on its own but let's take a look at an example of some basic usage so one more time I'm going to go over here to my snippets and grab a little bit of code here and this is going to be a new method in our employee class so I'm going to paste this at the bottom of our employee class and then fix these indentations so this is a sample method that we're going to pretend that goes to a company's website this line here using request gets and pulls down and employees scheduled for a given month and real quick I also have to import the request library here at the top so import requests and back down here in our method so we do the request get for this website for this employee and for this month to get their schedule and if the response is okay then we want to return the text of that response and if the response is not okay then we want to return the text bad response so the information from that website is something that we would want to mock because we don't want the success of our tests to depend on that website being up so we only care that the get method was called with the correct URL and that our code behaves correctly whether the response is okay and not okay so to do this let's import something from mock called hatch so up here at the top of our test employee module I will say from unit test dot mock import patch now there are a couple of different ways that we can use patch so either as a decorator or as a context manager and it will allow us to mock object during a test and then that object is automatically restored after the test is run so let's create a new test down here at the bottom for that monthly schedule method and we'll just call this test underscore monthly oops and I wanted to call that monthly schedule not monthly method and then we'll pass in self and so in this example we'll use patch as a context manager so we'll just say so what we said here was with patch and then within patch we pass what we want to mock and request get of the employee module and then we're setting that equal to mocked get now you may wonder why we didn't just import request into our test and just mock that instead of the employee request but we want to mock these objects where they're actually used so it's actually used in this employee module so that is the request get that we want to mock okay so now when requests that get is run in the employee module it's actually going to use our MOT get variable here instead of the regular get method and we can just assign the return value instead of actually going out to the website so we can test a successful call by saying mocked get dot return value and if we look back at our employee module we want that return value to have an okay of true so I can say return value dot okay is equal to true and let's also set the text of that return value so we can set the text equal to you know something like success so if we look here in employee module if it returns okay as true then we should get our response text back so now within our context manager here let's just run our monthly schedule method just like we're testing it so we can say schedule is equal to self dot employee one dot monthly schedule and we'll just pass in a value of may to get the may schedule now one more awesome thing about these mock objects is that they actually record when they were called and with what values so we want to make sure that the get method was called with the correct URL so to do this we can say mocked get dot assert called with and this is just a method of that mocked object and now we can test that it got called with the correct URL so since this is employee one here the last name is Schaefer right here so this should have been called with the URL HTTP company. com slash Schaefer and the month that we passed in was May and if you're wondering where I get that here in our employee class this is where it creates the URL here so it's saying HTTP company comm and then the employees last name and then the month that we passed in so that's the URL that it should have called that get method with now after we know that the method was called with the correct URL let's make sure that it returns the correct text which we set to success so let's say self dot assert equal and we want to assert that our schedule which is the response is equal to success okay so now if we run this code then we still have our print statements in here but we can see down here at the bottom that it ran for tests and that they all passed okay now last thing is that we want to test a failed response so to do this we can just do the exact same thing so I'll just copy all of this here and paste it in down below but instead of this okay value being true I'm going to set this to false so that'll test a bad response from the website and if that okay value isn't true then our monthly schedule function should just return the string bad response so we actually don't need this text value here at all so we can just remove that and just to switch the second test up a bit let's change our employee here to employee two and we'll use the month of June just to make these tests a little better so now the get method should be called with the URL of Smith which is our employee - if I scroll up here to the top you can see our employee - is Smith and then that month that we used is June so I'll save that and lastly instead of our result equaling success it should instead return the text bad response with an exclamation point so now if we run this then we can see that all of our tests are still passing so I know that this mocking can be a little confusing when you first see it and like I said it could probably be a video all on its own but you don't use it a whole lot unless you're you know accessing things like URLs and things that are basically out of your control so you don't use it a lot but whenever you do need it is definitely nice to know okay so I think that's going to about do it for this video but before we finish up here let me mention a few things about best practices so first of all like we saw in this video test should be isolated so if you're still unclear what that means basically this just means that your test should rely on other tests or effect other tests so you should be able to run any tests by itself independent of the other tests and one more thing that I wanted to mention is that you'll notice that in this video I was adding tests to existing code now you may have heard something called test-driven development and basically what test-driven development means is that you write the test before you write the code and I know that might sound a little strange but sometimes I've found it useful I don't strictly follow test-driven development to where it's something that I always do but basically the concept is that you should think about what you want your code to do and then write a test implementing that behavior then watch the test fail since it doesn't actually have any code to run against and then to write the code in a way that gets the test to pass so if you ever hear someone talking about test-driven development then that's what they're talking about okay so I think that is going to do it for this video I hope that everyone now has a good idea for how they can get started with unit testing now any testing is better than no testing so don't feel like you have to be an expert with mocks and things like that before you start writing any tests even if you just write some basic assertions then it's better than not having anything now there is another test framework out there called pi test that a lot of people like to use more than this built-in unit test library and I'll be doing a video on that in the near future so that you can compare the two and see which one you like better now if anyone has any questions about what we covered in this video then feel free to ask in the comment section below and I'll do my best to answer those and if you enjoyed these tutorials and would like to support them then there are several ways you can do that the easiest way is to simply like the video and give it a thumbs up and also it's a huge help to share these videos with anyone who you think would find them useful and if you have the means you can contribute through patreon and there's a link to that page in the description section below be sure to subscribe for future videos and thank you all for watching