A Simple Introduction to Automating Unit Tests in Python

“Unit Testing” is when you test one unit of your software independent of any other units. Typically in Object Oriented Development (OOD) this unit is a class. But, what is testing? In simple terms, testing means checking the output of your code against a set of pre-defined, correct expected output/results. You need to have test data — both input and expected output/results — before you start testing. I said “output/results” because sometimes your code doesn’t output data, rather it modifies some data in your software.

Now, manually testing your code i.e. running it yourself, entering input via a user interface and visually examining the results is gruellingly boring and no doubt cumbersome. Plus, this way of testing isn’t easily scalable or repeatable. Instead you could write a tester class that simply calls all your functions and compares the results with a set of pre-defined ones. However, the problem with this method is that the functions you are testing could call other functions which may run some code elsewhere and so on. This could really mess up the working of your software or even corrupt any valuable data you might have on your database. Remember Unit Testing is all about testing one thing at a time. The solution to this is writing isolated, automated tests with the help of tools like pytest, unittest and nose2.

Since the goal of this tutorial is not to delve deep into the intricacies of software testing, let’s head straight into writing some automated tests in Python. We will be using the unittest Python library to write tests and nose2 to run them.

We have here a Python class called “Customer”. The class has some basic functions that allow us to add and retrieve customer data. We are using a very basic python database called tinydb to store the data.

tinydb stores data in a JSON file in the same directory as the python code. You can instantiate the Customer class by providing a customer ID. But when you add a customer you have to provide the customer name, email and type and it will assume the customer ID given during instantiation. A customer is only added if they don’t already exist in the database and only loaded if they do exist.

It is very handy to have a test plan before you start writing tests. You should think of:

1- What your code does.

This includes (but is not limited to):

2- Good and bad case scenarios

When you think of the expected results you need to take into account both successful execution of your functionalities and anomalies that could occur.

Eg: Adding an already existing customer should result in a warning.

3- What does not require testing

Your program may include code where you invoke functions already tested. You don’t want to test them again. There could also be functions from external packages that you don’t have to bother about.

Eg: The tinydb insert function.

4- Of course, the tests themselves

Here we will need to write tests for the following functionalities:

Now let’s declare our class:

Our test class inherits from the TestCase class. Hence why we imported it earlier. A test class can be seen as a collection of tests, each test being a function inside it.

The “setUp” function is where we declare test data and anything else that we need to build our tests (Eg: a fake database, fake HTTP requests). It runs before any of the tests in the class. Also the “setUp” function is called every time a test is run. You can see we have declared some customer attributes in ours.

Okay, let’s write our first test:

So let’s rewrite our first test with mocking included:

Now, let’s write another test for the same function:

The test for the converse case would look like this:

At the top of every test you can see that there is a patch decorator above every test. To avoid this code duplication we can transfer it to the top of our test class. We still need to keep the corresponding parameter (right at the end).

You have now reached the simplest part of the process! All you have to do to run your tests is typing in nose2 on your CLI from your project directory.

Running nose2 --coverage term-missing --with-coverage will give you a detailed report of how much of your code has been covered by your tests.

Hope this guide helped you learn something new!

Cover Photo:

Related posts:

Award-winning director creates voice-activated Augmented Reality Experience that boosts children’s confidence At first glance, Little Red the Inventor is a rather sweet-looking little AR app where…

Photography is more than just taking pictures and putting them in a frame. It is about encapsulating the world we live in today and being able to preserve it for years to come. It amazes me that we…

Melissa Etheridge performs sold out concert at Parx Casino’s Xcite Center, featuring hits like ‘I’m the Only One’ Most female performers go through a handful of wardrobe changes in the span of a…